Re: [yocto] Installing the SDKs made with meta-mingw

[Christopher Larson]

On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
wrote:

> I've successfully built a Canadian-cross SDK using the meta-mingw layer.
> Very nice!
>
> Because the layer lobotomizes the SDK_PACKAGING_FUNC when ${SDKMACHINE} is
> set to a MinGW host, though, the resulting SDK is not encapsulated into the
> self-extracting tarball and the corresponding relocation logic (
> relocate_sdk.py and so forth) is omitted.
>
> Any suggestions on how to do the last-mile work to use the SDK on Windows?
> Or perhaps nothing is needed at all, except adjusting the prefixes built
> into environment-setup-? Although that would be nice, I think at
> least some installation-time adjustment is necessary though; when I do:
>
> arm-poky-linux-gnueabi-gcc -o foo foo.c
> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>
> , the following happens during linking:
>
> ld.exe: cannot find /lib/libc.so.6 inside
> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>

Mark Hatle's branch switches to batch files for environment setup and
whatnot. I don't know if it addresses the reloc issue or not, but it's a
substantial improvement over master. See
https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Are there any places that you can use the crosswalk latest version?

[Burton, Ross]

On 17 March 2016 at 03:03, 윤영석  wrote:

> So, i had try to found crosswalk recipes,
>
> finally i got it. but it is not lately version. (version : 12.40.295.0)
>
> refer under the link,
>
> https://github.com/crosswalk-project/meta-crosswalk
>

I suggest you try asking the crosswalk developers (either their list or
IRC), as it's their recipe that needs updating.

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

[yocto] [meta-raspberry] Raspberry Pi 3

[David Weisgerber]

Hi,
did anyone succeed in building an image that runs on Raspberry Pi 3? I set my 
conf/local.conf to

MACHINE ??= "raspberrypi3" 
GPU_MEM = "128" 
DISABLE_OVERSCAN = "1"

and built rpi-basic-image but when booting the Pi 3 up I only see 4 
raspberries in the top right but nothing else happens. The image works 
perfectly on a Pi 2 though.

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

Re: [yocto] Problems building live image

[Rudolf J Streif]

On Monday, March 14, 2016 04:38:35 PM K Richard Pixley wrote:
> 
> What stops us from building different boot labels for different images?  
> That seems like the obvious choice.  Or perhaps, using "boot" for all 
> syslinux images and adding "install" for "live" images.

Fair question. Nothing really, I would think. The classes need to be adjusted 
to deal with different LABELS.
 :rjs
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][layerindex-web] search: only match pn against search string for recipe searches

[Elliot Smith]

Using the search box creates a query against the pns,
summaries, descriptions and filenames of recipes.
This results in a lot of spurious results for common terms
like "git" when performing a recipe search.

Reduce the search fields used to just the pn so that the search
will only return results where the recipe name matches.

[YOCTO #9159]

Signed-off-by: Elliot Smith 
---
 layerindex/views.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/layerindex/views.py b/layerindex/views.py
index 7e877ac..2dbde24 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -373,7 +373,7 @@ class RecipeSearchView(ListView):
 query_string = self.request.GET.get('q', '')
 init_qs = 
Recipe.objects.filter(layerbranch__branch__name=self.kwargs['branch'])
 if query_string.strip():
-entry_query = simplesearch.get_query(query_string, ['pn', 
'summary', 'description', 'filename'])
+entry_query = simplesearch.get_query(query_string, ['pn'])
 qs = init_qs.filter(entry_query).order_by('pn', 
'layerbranch__layer')
 else:
 if 'q' in self.request.GET:
@@ -689,7 +689,7 @@ class ClassicRecipeSearchView(RecipeSearchView):
 if category:
 init_qs = init_qs.filter(classic_category__icontains=category)
 if query_string.strip():
-entry_query = simplesearch.get_query(query_string, ['pn', 
'summary', 'description', 'filename'])
+entry_query = simplesearch.get_query(query_string, ['pn'])
 qs = init_qs.filter(entry_query).order_by('pn', 
'layerbranch__layer')
 else:
 if 'q' in self.request.GET:
-- 
1.9.3

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[yocto] [PATCH] matchbox-keyboard-ui.c: Fix int -> long to address 32bit vs 64 bit addressing

[Saul Wold]

The soft keyboard was displaying incorrectly on 64bit machines

[YOCTO #9254]

Signed-off-by: Saul Wold 
---
 src/matchbox-keyboard-ui.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/matchbox-keyboard-ui.c b/src/matchbox-keyboard-ui.c
index 84bc375..988504e 100644
--- a/src/matchbox-keyboard-ui.c
+++ b/src/matchbox-keyboard-ui.c
@@ -125,7 +125,7 @@ get_desktop_area(MBKeyboardUI *ui, int *x, int *y, int 
*width, int *height)
   Atom   atom_area, type;
   intresult, format;
   unsigned long  nitems, bytes_after;
-  int   *geometry = NULL;
+  long   *geometry = NULL;
 
   atom_area = XInternAtom (ui->xdpy, "_NET_WORKAREA", False);
 
-- 
2.5.0

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

Re: [yocto] Re: Re: Qt5.6 new modules

[idealsim]

It seems that they have a problem with c++11, see QTBUG-51655, change 
comit 
https://github.com/qtproject/qtserialbus/commit/04b75569f36eec14662505a08bf8c1d565cb10fe


The SRCREV is now 04b75569f36eec14662505a08bf8c1d565cb10fe

Seems to work ! compil the lib ...

Continue to build the master image now

Mickaël

Le 18/03/2016 11:39, Christian Ege a écrit :

Hi,

2016-03-18 10:00 GMT+01:00 idealsim :

Hi and thank you, now i know where to find SRCREV !
After adjust this variable and LICENSE.FDL the source is fetched. My bb :

require qt5.inc
require qt5-git.inc

# There are no LGPLv3-only licensed files in this component.
# There are no GPLv2 licensed files in this component.
LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 & The-Qt-Company-Qt-LGPL-Exception-1.1
| LGPL-3.0)"
LIC_FILES_CHKSUM = " \
 file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
 file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
 file://LICENSE.FDL;md5=f70ee9a6c44ae8917586fea34dff0ab5 \
 file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
"

DEPENDS += "qtbase qtserialport"

SRCREV = "92c979c6652d55c30ab9118d45db74d8da96fc3b"

When i launch bitbake qtserialbus, the process build without error, but it
seems there is something missing because the compile step is very fast and
my
neoBuild/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtserialbus/5.5.99+5.6.0-rc+gitAUTOINC+92c979c665-r0/package/
folder is empty ! If i take the qtsensors folder, there are this folder (in
package) :
usr/
 include/
 lib/
 src/

I'm looking to meta-qt5 BSP to find where i can precise to build my new
recipe but didn't find anything can help. Do you know how to proceed ?

You can execute a bitbake with option -v so You'll see the output. But
When the package was previously build you should clean stuff before

bitbake -ccleansstate qtserialbus
bitbake -v qtserialbus

Best,
Christian

regards,

Le 18/03/2016 08:16, Christian Ege a écrit :

Hi,

2016-03-17 17:16 GMT+01:00 idealsim :

Hi, i have started a build of the image this master Branch, like you said i
have an error on qtserialbus :

WARNING: Failed to fetch URL
git://github.com/qtproject/qtserialbus.git;name=qtserialbus;branch=5.6;protocol=git,
attempting MIRRORS if available
ERROR: Fetcher failure: Unable to find revision
6a16281aceedb713676e16c3074e6f7ea1e70b79 in branch 5.6 even from upstream
ERROR: Function failed: Fetcher failure for URL:
'git://github.com/qtproject/qtserialbus.git;name=qtserialbus;branch=5.6;protocol=git'.
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in:
/media/modjo/data1TO/yocto/seco/udoo-community-bsp/neoBuild/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtserialbus/5.5.99+5.6.0-rc+gitAUTOINC+6a16281ace-r0/temp/log.do_fetch.5862
ERROR: Task 894
(/media/modjo/data1TO/yocto/seco/udoo-community-bsp/sources/meta-qt5/recipes-qt/qt5/qtserialbus_git.bb,
do_fetch) failed with exit code '1'

This is my qtserialbus_git.bb :

require qt5.inc
require qt5-git.inc

# There are no LGPLv3-only licensed files in this component.
# There are no GPLv2 licensed files in this component.
LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 & The-Qt-Company-Qt-LGPL-Exception-1.1
| LGPL-3.0)"
LIC_FILES_CHKSUM = " \
 file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
 file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
 file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \
 file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
"

DEPENDS += "qtbase qtserialport"

SRCREV = "6a16281aceedb713676e16c3074e6f7ea1e70b79"

The SRCREV is the git SHA1 of the repository qtserialbus. For the 5.6
Branch the latest one is:

SRCREV = "92c979c6652d55c30ab9118d45db74d8da96fc3b"


You can check the SHA1s here:
https://github.com/qtproject/qtserialbus/commits/5.6

The MD5 Sums will be complained during configure step and bitbake wil
tell you the right ones.
Please check if the Licences do match

Regards,
Christian

An idea is welcome !

Regards,

Mickaël



Le 16/03/2016 14:57, idealsim a écrit :

Thanks for the tip. I will try it out and let you know ...

Regards,

Mickaël

Le 16/03/2016 10:17, Christian Ege a écrit :

Hi,,

2016-03-16 9:04 GMT+01:00 idealsim :

Hi, we have build an image for udoo neo from meta-qt5 jansa/master-5.6 and
works fine (thanks to Christian Ege ). The problem is that I'm looking for
https://github.com/qtproject/qtquickcontrols2 and
https://github.com/qtproject/qtserialbus. My question is how we can add this
modules to our build ?  I add this to our local.conf :

  "qtquickcontrols2 \
   qtserialbus \
  "
But this modules don't have buildable providers ! If someone can help to
said me how to proceed ...

You can try to add a meta-qt5/recipes-qt/qt5/qtserialbus_git.bb and
take for example meta-qt5/recipes-qt/qt5/qtsensors_git.bb as reference

require qt5.inc
require qt5-git.inc
# There are no LGPLv3-only licensed files in 

Re: [yocto] [matchbox-wm][PATCH] ewmh: Fix data type of a few XChangeProperty calls

[Burton, Ross]

On 18 March 2016 at 15:11, Jussi Kukkonen  wrote:

> XChangeProperty documentation: "If the specified format is 32, the
> property data must be a long array."
>
> Using int can lead to bogus data being used on platforms where long
> actually is different from int.
>
> Signed-off-by: Jussi Kukkonen 
>

Pushed, thanks Jussi!

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

Re: [yocto] Installing the SDKs made with meta-mingw

[Christopher Larson]

On Thu, Mar 17, 2016 at 9:48 AM Matt Hoosier  wrote:

> On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson 
> wrote:
>
>>
>>
>> On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson 
>> wrote:
>>
>>> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier 
>>> wrote:
>>>
 On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
 wrote:

>
>
> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson <
> clar...@kergoth.com> wrote:
>
>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier > > wrote:
>>
>>> I've successfully built a Canadian-cross SDK using the meta-mingw
>>> layer. Very nice!
>>>
>>> Because the layer lobotomizes the SDK_PACKAGING_FUNC when
>>> ${SDKMACHINE} is set to a MinGW host, though, the resulting SDK is not
>>> encapsulated into the self-extracting tarball and the corresponding
>>> relocation logic (relocate_sdk.py and so forth) is omitted.
>>>
>>> Any suggestions on how to do the last-mile work to use the SDK on
>>> Windows? Or perhaps nothing is needed at all, except adjusting the 
>>> prefixes
>>> built into environment-setup-? Although that would be nice, I
>>> think at least some installation-time adjustment is necessary though; 
>>> when
>>> I do:
>>>
>>> arm-poky-linux-gnueabi-gcc -o foo foo.c
>>> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>>
>>> , the following happens during linking:
>>>
>>> ld.exe: cannot find /lib/libc.so.6 inside
>>> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>>
>>
> As it turns out, the immediate error here was simply that libc.so.6
> did not exist, so ld.exe was telling the truth in this case. The symbolic
> links stored in the SDK tarball that would have created libc.so.6 aren't
> meaningful on Windows, so tar just ignores them when unpacking. Presumably
> some fancier handling of the tarball unpacking to simulate symlinks by
> making copies of the pointed-to file would cure this.
>
>
>>
>> Mark Hatle's branch switches to batch files for environment setup and
>> whatnot. I don't know if it addresses the reloc issue or not, but it's a
>> substantial improvement over master. See
>> https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
>>
>
> Thanks, I'll try that.
>

 Mark Hatle's branch does work much more nicely for that. There's still
 the problem of what to do with the symlink from the SDK tarballs. Are there
 any regular users of these mingw SDKs out there who know the right
 expectation on how to extract them?

>>>
>>> tar has an option to resolve symlinks to the files, I'd expect you could
>>> just add that to the variable for the tar options for the sdk, and it'd
>>> just duplicate the symlinks. You'll have extra files, so it'd be larger,
>>> but at least it'd be functional.
>>>
>>
>> Erm, I meant duplicate the files, not the symlinks :) The symlinks would
>> be resolved to files. Clearly I haven't had enough caffeine yet today.
>>
>
> Thanks.
>
> If you're thinking of "tar -h -xf ... ", I'd given that a try prior to my
> previous message. It doesn't seem to have any effect on the outcome (at
> least, for the copy of 'tar' bundled into my installation of MinGW and
> MSys).
>

No, I was thinking of changing the tar *creation* rather than extraction,
so the symlinks are followed and stored as files in the tarball.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Compiling kernel 4.4

[SIVA SUBRAMANIAN.P]

Hi,
While compiling linux kernel 4.4 for 96boards, I'm getting below error
even though openssl headers are available in sysroot path.

|   HOSTCC  scripts/selinux/mdp/mdp
| 
/mnt/home/knagabhirava/hikey/build/tmp-glibc/work-shared/hikey/kernel-source/scripts/extract-cert.c:21:25:
fatal error: openssl/bio.h: No such file or directory
|  #include 
|  ^
| compilation terminated.

ERROR: Task 6 
(/mnt/home/knagabhirava/hikey/build/../meta-96boards/recipes-kernel/linux/linux-96boards_git.bb,
do_compile) failed with exit code '1'

Any idea/pointers?

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

Re: [yocto] Possible introspection failure in master

[Burton, Ross]

On 17 March 2016 at 09:37, Andre McCurdy  wrote:

> As an aside, I'm not sure that using DISTRO/MACHINE_FEATURES_BACKFILL
> for gobject-introspection-data is entirely correct since gobject
> introspection is not a feature which was previously enabled by
> default:
>

That is true.  Maybe we should just add it to the default distro features
and remove it from backfill.  I don't suppose you could make a patch?

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

[yocto] [meta-qt5] [meta-mingw] Any success using these two layers together?

[Matt Hoosier]

Does anybody have experience using meta-qt5 and meta-ming together to
produce a usable SDK including Qt development tools for use on a Windows
host together?

The stock recipes for producing the nativesdk flavors of certain Qt
packages would seem to require some modification from vanilla meta-qt5
upstream to be able to target mingw.

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

Re: [yocto] [master] ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot:

[Martin Jansa]

Delete your TMPDIR and start again.

On Wed, Mar 16, 2016 at 8:29 PM, Christian Ege  wrote:

> Hi,
>
> with the latest master from today I ran in some trouble:
>
> Build Configuration:
> BB_VERSION= "1.29.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "udooneo"
> DISTRO= "poky"
> DISTRO_VERSION= "2.0+snapshot-20160316"
> TUNE_FEATURES = "arm armv7a vfp thumb neon
> callconvention-hard   cortexa9"
> TARGET_FPU= "hard"
> meta
> meta-poky = "HEAD:8debfea81e69d038bd2d56314b272cb74f5582ed"
> meta-oe
> meta-multimedia
> meta-python
> meta-networking   = "HEAD:35d91f32c462ad5889cb3229766d6d4ed2c80a4c"
> meta-qt5  = "master-5.6:b2d5376b41625521b9a081fe800345fff33d8dd6"
> meta-ruby = "HEAD:35d91f32c462ad5889cb3229766d6d4ed2c80a4c"
> meta-fsl-arm  = "HEAD:37564e6801ce82fad979b4f57151c676d80e8a6c"
> meta-fsl-arm-extra = "HEAD:36a638abe1238bdc8e0ef1242dd7bfab59cc48d7"
> meta-fsl-demos= "HEAD:6b779b2cb0d231063fc035a9a0871d722366c329"
> meta-udoo = "master:1b38bcec5057b93017a00f107e0738ce64ade66f"
> meta-swupdate = "master:44516e81a494afef3be7e3f249713fdec6e6e32a"
>
> NOTE: Preparing RunQueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot: The recipe
> gobject-introspection is trying to install files into a shared area
> when those files already exist. Those files and their manifest
> location are:
>
>  
> /data/FSL/fsl-community-bsp-master/build/tmp/sysroots/udooneo/usr/share/gobject-introspection-1.0/Makefile.introspection
>  Matched in manifest-udooneo-gtk-doc-stub.populate_sysroot
>
>  
> /data/FSL/fsl-community-bsp-master/build/tmp/sysroots/udooneo/usr/share/aclocal/introspection.m4
>  Matched in manifest-udooneo-gtk-doc-stub.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: gobject-introspection-1.46.0-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: gobject-introspection-1.46.0-r0 do_populate_sysroot: Function
> failed: sstate_task_postfunc
> ERROR: Logfile of failure stored in:
>
> /data/FSL/fsl-community-bsp-master/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gobject-introspection/1.46.0-r0/temp/log.do_populate_sysroot.16494
> ERROR: Task 1802
>
> (/data/FSL/fsl-community-bsp-master/sources/poky/meta/recipes-gnome/gobject-introspection/
> gobject-introspection_1.46.0.bb,
> do_populate_sysroot) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 4772 tasks of which 4742 didn't need to
> be rerun and 1 failed.
> No currently running tasks (4772 of 5254)
>
>
> Any help is appreciated.
>
> Best,
> Christian
>
> --
> http://ch.ege.io/
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Not able to disable introspection in gstreamer

[Ashish Shrivastava]

?Hi,


I am trying to build latest poky version from upstream but it was failing in 
"gobject-introspection-data?".

I disabled it with comments mentioned in:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?id=8c14c746da1784c4bdaa621dde6fccd99e72ef1b


by adding folloing line in config:

MACHINE_FEATURES_BACKFILL_CONSIDERED = "gobject-introspection-data"


Now gstreamer is throwing error for introspection.


I am trying to disable it but with no success.


Anyone who knows how to disable introspection in gstreamer would be of great 
help.


Regards

Ashish

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

[yocto] [master] ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot:

[Christian Ege]

Hi,

with the latest master from today I ran in some trouble:

Build Configuration:
BB_VERSION= "1.29.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "udooneo"
DISTRO= "poky"
DISTRO_VERSION= "2.0+snapshot-20160316"
TUNE_FEATURES = "arm armv7a vfp thumb neon
callconvention-hard   cortexa9"
TARGET_FPU= "hard"
meta
meta-poky = "HEAD:8debfea81e69d038bd2d56314b272cb74f5582ed"
meta-oe
meta-multimedia
meta-python
meta-networking   = "HEAD:35d91f32c462ad5889cb3229766d6d4ed2c80a4c"
meta-qt5  = "master-5.6:b2d5376b41625521b9a081fe800345fff33d8dd6"
meta-ruby = "HEAD:35d91f32c462ad5889cb3229766d6d4ed2c80a4c"
meta-fsl-arm  = "HEAD:37564e6801ce82fad979b4f57151c676d80e8a6c"
meta-fsl-arm-extra = "HEAD:36a638abe1238bdc8e0ef1242dd7bfab59cc48d7"
meta-fsl-demos= "HEAD:6b779b2cb0d231063fc035a9a0871d722366c329"
meta-udoo = "master:1b38bcec5057b93017a00f107e0738ce64ade66f"
meta-swupdate = "master:44516e81a494afef3be7e3f249713fdec6e6e32a"

NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot: The recipe
gobject-introspection is trying to install files into a shared area
when those files already exist. Those files and their manifest
location are:
   
/data/FSL/fsl-community-bsp-master/build/tmp/sysroots/udooneo/usr/share/gobject-introspection-1.0/Makefile.introspection
 Matched in manifest-udooneo-gtk-doc-stub.populate_sysroot
 
/data/FSL/fsl-community-bsp-master/build/tmp/sysroots/udooneo/usr/share/aclocal/introspection.m4
 Matched in manifest-udooneo-gtk-doc-stub.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: gobject-introspection-1.46.0-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: gobject-introspection-1.46.0-r0 do_populate_sysroot: Function
failed: sstate_task_postfunc
ERROR: Logfile of failure stored in:
/data/FSL/fsl-community-bsp-master/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gobject-introspection/1.46.0-r0/temp/log.do_populate_sysroot.16494
ERROR: Task 1802
(/data/FSL/fsl-community-bsp-master/sources/poky/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb,
do_populate_sysroot) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4772 tasks of which 4742 didn't need to
be rerun and 1 failed.
No currently running tasks (4772 of 5254)


Any help is appreciated.

Best,
Christian

-- 
http://ch.ege.io/


log.do_populate_sysroot.16494
Description: Binary data
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Compiling raspberry2 with eglinfo-x11

[David Weisgerber]

Hi all,
I just wanted to add that I got the qt5everywheredemo running. However it 
seems as changing the GPU_MEM variable is not picked up correctly when 
changing it. I had to change my boot type to uImage (which did work because 
the raspberry pi did not boot up with it) and back, then I had the desired 
amount of video ram and the demo was working.

Regarding picking up variables: My override to the yocto splash image does not 
work always as well. Sometimes my image is taken and some times the yocto 
splash image. Just seems random to me. Are there any logs where you can see 
why what bbappend was applied?

Thank you very much,
David Weisgerber

On Thursday, March 17, 2016 10:17:56 AM David Weisgerber wrote:
> Hi,
> I got Qt to compile by solving the following "problem" in the userland EGL /
> GLESv2 code:
> # Khronos
> #
> # Note: in Android the linker is unable or unwilling to resolve
> # dynamically using already loaded symbols. The libraries here
> # have quite a few circular dependencies, and so the only way
> # to make it work seems to be to have everything static.
> 
> There is a circular dependency between libEGL and libGLESv2. You can fix the
> Qt compile by adding the following qtbase_%.bbappend:
> do_configure_prepend_rpi() {
> cat > ${S}/mkspecs/oe-device-extra.pri << 'EOF'
> EGLFS_DEVICE_INTEGRATION = eglfs_brcm
> QMAKE_INCDIR_EGL = $$[QT_SYSROOT]${includedir}/interface/vmcs_host/linux
> QMAKE_INCDIR_OPENGL_ES2 = $${QMAKE_INCDIR_EGL}
> QMAKE_LIBS_EGL = -lEGL -lGLESv2
> EOF
> }
> 
> which just changes the order of linking to the libraries.
> 
> However, I am still not able to get the Qt eglfs programs running due to the
> following problem:
> * failed to add service - already in use?
> which must be coming from the userland code
> 
> My problem could be caused by the fact, that changing GPU_MEM does not seem
> to have any effect atm and the vc4 driver isn't loaded at startup...
> 
> Thanks for help,
> David
> 
> On Thursday, March 17, 2016 12:41:17 PM SIVA SUBRAMANIAN. P wrote:
> > What is your preferred GLES provider set to, userland or mesa?
> > 
> > On Wed, Mar 16, 2016 at 8:51 PM, David Weisgerber
> > 
> >  wrote:
> > > Hi,
> > > 
> > > I have problems compiling eglinfo-x11 (as well as Qt 5 from meta-qt5)
> > > with
> > > egl.
> > > 
> > > I have setup poky, meta-raspberrypi (and meta-qt5) from git and I am on
> > > branch master.
> > > 
> > > My target is to get a distribution with working (hw acceleratetd) Qt5
> > > with
> > > QML GUI. I have already spent some days on getting qteverywheredemo
> > > running
> > > but I did not succeed yet.
> > > 
> > > As a first test I wanted to get eglinfo-x11 running but it gives the
> > > following error when compiling:
> > > 
> > > [11/11] cxxprogram: build/release/src/json_writer.cpp.1.o
> > > build/release/src/log.cpp.1.o build/release/src/main.cpp.1.o
> > > build/release/src/process_egl.cpp.1.o build/release/src/scopes.cpp.1.o
> > > build/release/src/text_writer.cpp.1.o
> > > build/release/src/json-sax/json.c.1.o
> > > b
> > > uild/release/src/platform_x11_generic.cpp.1.o
> > > build/release/src/openvg_stats.cpp.1.o
> > > build/release/src/process_openvg.cpp.1.o -> build/release/eglinfo
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glDiscardFramebufferEXT'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glPointSizePointerOES'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glxx_set_error_api'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glxx_client_BindFramebuffer'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glintAttribPointer'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glxx_client_state_free'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glxx_client_FramebufferRenderbuffer'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glxx_buffer_info_set'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glxx_set_error'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glxx_client_DeleteFramebuffers'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `gl11_client_state_init'
> > > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so
> > > :
> > > undefined reference to `glxx_client_GetFramebufferAttachmentParameteriv'
> > > 

Re: [yocto] Not able to disable introspection in gstreamer

[Martin Jansa]

On Wed, Mar 16, 2016 at 02:54:27PM +, Ashish Shrivastava wrote:
> ?Hi,
> 
> 
> I am trying to build latest poky version from upstream but it was failing in 
> "gobject-introspection-data?".
> 
> I disabled it with comments mentioned in:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?id=8c14c746da1784c4bdaa621dde6fccd99e72ef1b
> 
> 
> by adding folloing line in config:
> 
> MACHINE_FEATURES_BACKFILL_CONSIDERED = "gobject-introspection-data"
> 
> 
> Now gstreamer is throwing error for introspection.
> 
> 
> I am trying to disable it but with no success.
> 
> 
> Anyone who knows how to disable introspection in gstreamer would be of great 
> help.

Our gstreamer recipes are also failing even when COMBINED_FEATURES don't
contain gobject-introspection-data (I've used
DISTRO_FEATURES_BACKFILL_CONSIDERED because I want to disable it for all
MACHINEs).

I think it's because COMBINED_FEATURES conditional is used only to add
--enable-introspection in EXTRA_OECONF, but other changes like
introspection.m4 changes are done in all builds.

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


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

Re: [yocto] Possible introspection failure in master

[Andre McCurdy]

On Thu, Mar 17, 2016 at 1:57 AM, Chris Tapp  wrote:
> I’m trying to build gstreamer1.0-plugins-base_git.bb under master. 
> Compilation is failing with:

The gstreamer _git recipes have not been updated to include the
gobject introspection patches which were applied to the 1.6.3 recipes.

Try disabling gobject introspection via DISTRO or MACHINE features, ie:

  MACHINE_FEATURES_BACKFILL_CONSIDERED_append = " gobject-introspection-data"

or

  DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " gobject-introspection-data"


As an aside, I'm not sure that using DISTRO/MACHINE_FEATURES_BACKFILL
for gobject-introspection-data is entirely correct since gobject
introspection is not a feature which was previously enabled by
default:

  
http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-features-backfill

>
> | g-ir-scanner: link: ../../../libtool --mode=link --tag=CC 
> x86_64-poky-linux-gcc -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 
> --sysroot=/media/SSD-Build/build-jethro-opty4-v2/tmp/sysroots/valleyisland-64 
> -o 
> /media/SSD-Build/build-jethro-opty4-v2/tmp/work/corei7-64-poky-linux/gstreamer1.0-plugins-base/1.7.2+gitAUTOINC+97e108beba-r0/build/gst-libs/gst/fft/tmp-introspectIeb9nD/GstFft-1.0
>  -export-dynamic -O2 -pipe -g -feliminate-unused-debug-types 
> -fdebug-prefix-map=/media/SSD-Build/build-jethro-opty4-v2/tmp/work/corei7-64-poky-linux/gstreamer1.0-plugins-base/1.7.2+gitAUTOINC+97e108beba-r0/build=/usr/src/gstreamer1.0-plugins-base
>  
> -fdebug-prefix-map=/media/SSD-Build/build-jethro-opty4-v2/tmp/work/corei7-64-poky-linux/gstreamer1.0-plugins-base/1.7.2+gitAUTOINC+97e108beba-r0/git=/usr/src/gstreamer1.0-plugins-base
>  
> -fdebug-prefix-map=/media/SSD-Build/build-jethro-opty4-v2/tmp/sysroots/x86_64-linux=
>  
> -fdebug-prefix-map=/media/SSD-Build/build-jethro-opty4-v2/tmp/sysroots/valleyisland-64=
>  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
> tmp-introspectIeb9nD/media/SSD-Build/build-jethro-opty4-v2/tmp/work/corei7-64-poky-linux/gstreamer1.0-plugins-base/1.7.2+gitAUTOINC+97e108beba-r0/build/gst-libs/gst/fft/tmp-introspectIeb9nD/GstFft-1.0.o
>  -L. libgstfft-1.0.la -lgio-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread 
> -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0
> | Caught exception:  OSError(2, 'No such file or 
> directory')
> | > 
> /media/SSD-Build/build-jethro-opty4-v2/tmp/sysroots/x86_64-linux/usr/lib/python2.7/subprocess.py(1335)_execute_child()
> | -> raise child_exception
> | (Pdb)
>
> I’ve tried removing tmp/ and cleansstate but this didn’t help.
>
> I’m not sure what to try next. Any pointers?
>
> --
>
> Chris Tapp
> opensou...@keylevel.com
> www.keylevel.com
>
> 
> You can tell you're getting older when your car insurance gets real cheap!
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing the SDKs made with meta-mingw

[Matt Hoosier]

On Thu, Mar 17, 2016 at 11:56 AM, Christopher Larson 
wrote:

>
>
> On Thu, Mar 17, 2016 at 9:48 AM Matt Hoosier 
> wrote:
>
>> On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson > > wrote:
>>
>>>
>>>
>>> On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson 
>>> wrote:
>>>
 On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier 
 wrote:

> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
> wrote:
>
>>
>>
>> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson <
>> clar...@kergoth.com> wrote:
>>
>>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier <
>>> matt.hoos...@gmail.com> wrote:
>>>
 I've successfully built a Canadian-cross SDK using the meta-mingw
 layer. Very nice!

 Because the layer lobotomizes the SDK_PACKAGING_FUNC when
 ${SDKMACHINE} is set to a MinGW host, though, the resulting SDK is not
 encapsulated into the self-extracting tarball and the corresponding
 relocation logic (relocate_sdk.py and so forth) is omitted.

 Any suggestions on how to do the last-mile work to use the SDK on
 Windows? Or perhaps nothing is needed at all, except adjusting the 
 prefixes
 built into environment-setup-? Although that would be nice,
 I think at least some installation-time adjustment is necessary though;
 when I do:

 arm-poky-linux-gnueabi-gcc -o foo foo.c
 --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi

 , the following happens during linking:

 ld.exe: cannot find /lib/libc.so.6 inside
 d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi

>>>
>> As it turns out, the immediate error here was simply that libc.so.6
>> did not exist, so ld.exe was telling the truth in this case. The symbolic
>> links stored in the SDK tarball that would have created libc.so.6 aren't
>> meaningful on Windows, so tar just ignores them when unpacking. 
>> Presumably
>> some fancier handling of the tarball unpacking to simulate symlinks by
>> making copies of the pointed-to file would cure this.
>>
>>
>>>
>>> Mark Hatle's branch switches to batch files for environment setup
>>> and whatnot. I don't know if it addresses the reloc issue or not, but 
>>> it's
>>> a substantial improvement over master. See
>>> https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
>>>
>>
>> Thanks, I'll try that.
>>
>
> Mark Hatle's branch does work much more nicely for that. There's still
> the problem of what to do with the symlink from the SDK tarballs. Are 
> there
> any regular users of these mingw SDKs out there who know the right
> expectation on how to extract them?
>

 tar has an option to resolve symlinks to the files, I'd expect you
 could just add that to the variable for the tar options for the sdk, and
 it'd just duplicate the symlinks. You'll have extra files, so it'd be
 larger, but at least it'd be functional.

>>>
>>> Erm, I meant duplicate the files, not the symlinks :) The symlinks would
>>> be resolved to files. Clearly I haven't had enough caffeine yet today.
>>>
>>
>> Thanks.
>>
>> If you're thinking of "tar -h -xf ... ", I'd given that a try prior to my
>> previous message. It doesn't seem to have any effect on the outcome (at
>> least, for the copy of 'tar' bundled into my installation of MinGW and
>> MSys).
>>
>
> No, I was thinking of changing the tar *creation* rather than extraction,
> so the symlinks are followed and stored as files in the tarball.
>

Ah. In that case, this is apparently a situation with no good general
solution. The conf files used in meta-mingw make a point of saying not to
attempt that, as it's been observed to result in infinite loops at tarball
creation-time. The particular blurb in question says:

# Causes an endless loop
#SDKTAROPTS_append = "-h --hard-dereference"

The commit that adopted this policy says that the looping is triggered on
certain cross-compilers' complements of system headers. That seems like
something I can test for and be fairly confident whether or not it'll
strike my particular configuration, so I imagine the symlink expansion can
safely be re-enabled on site-local configurations with little risk.

Thanks for the suggestions.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] Review request: [linux-yocto-3.14] Fix up the openvswitch kernel module compile failure.

[Bruce Ashfield]

On 2016-03-16 4:46 AM, guojian.z...@windriver.com wrote:

From: Guojian Zhou 

This patch based on the upstream commit 
6f6e8414631dd4bde7e0e29e9cab41d7e7c92970.

==
The following changes since commit 9ecf35fa7cdbf519acacc51b461a6f05fd096e09:

   aufs: import aufs core (2016-03-03 10:32:39 -0500)

are available in the git repository at:

   https://github.com/GuojianZhou/linux-yocto-3.14.git standard/base


Thanks for the fix, most appreciated.

Merged.

Bruce



for you to fetch changes up to e6c6de405a3fedda3ea66b84e61e1080e6a036d7:

   openvswitch:Fix the ovs_flow_mask_key() arguments missing issue in the 
datapath.c (2016-03-16 00:42:24 -0700)


Guojian Zhou (1):
   openvswitch:Fix the ovs_flow_mask_key() arguments missing issue in the 
datapath.c

  net/openvswitch/datapath.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)



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

[yocto] Are there any places that you can use the crosswalk latest version?

[윤영석]

Dear, all.
 
I want to use crosswalk in the yocto recipes.
 
So, i had try to found crosswalk recipes, 
finally i got it. but it is not lately version. (version : 12.40.295.0)
refer under the link, 
https://github.com/crosswalk-project/meta-crosswalk 
 
 
I can checking the crosswalk lately version under the link, (version : 
18.48.477.8) 
https://github.com/crosswalk-project/crosswalk 
commit a1f49d2afa2460576506adfd9bd28ec3ca6553e4 (HEAD, 
refs/remotes/origin/crosswalk-18, refs/heads/c
Author: Crosswalk Release Engineering 
crosswalk-...@lists.crosswalk-project.org
Date:   Thu Mar 10 14:08:22 2016 +


Bump version to 18.48.477.8 


Are there any places that you can use the latest version?
Thank you.Best Regards.
 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Conditional compile for package in layer.conf for Qemu

[YUKATHARSANI JEYACHANDRA]

You can use BBMASK variable in your layer.conf file.

From: yocto-boun...@yoctoproject.org  on behalf 
of Mark T 
Sent: Friday, March 18, 2016 11:02:54 PM
To: Andre McCurdy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Conditional compile for package in layer.conf for Qemu

Ross,

Thanks, that  " IMAGE_INSTALL_append_intel-corei7-64 = "package_b" "  worked a 
treat.

If I want to exclude a recipe from a layer for qemu builds  - is there a 
similar method for that ?

Thanks,
Mark


On 17 March 2016 at 09:10, Andre McCurdy 
> wrote:
On Wed, Mar 16, 2016 at 2:01 AM, Burton, Ross 
> wrote:
>
> On 16 March 2016 at 08:56, Mark T 
> > wrote:
>>
>> I'd like to be able to do the following
>>
>> IMAGE_INSTALL_append += "package_a"

It's not typical usage to combine += with _append, pick one or the other.

Using _append is generally more reliable if you're not sure how the
variable you're appending to was originally initialised, however with
_append you need to manually include a leading space character, ie:

IMAGE_INSTALL_append = " package_a"

>> if ( not qemu )
>> IMAGE_INSTALL_append += "package_b"
>> endif
>
>
> The neater way would be if you can easily identify what "not qemu" is, for
> example:
>
> IMAGE_INSTALL_append_intel-corei7-64 = "package_b"
>
> Would install package_b only for intel-corei7-64 machines.
>
> If you want to support arbitrary machines but not qemu then something like
> this might work:
>
> MOREDEPS = "package_b"
> MOREDEPS_qemuall = ""
> IMAGE_INSTALL_append = " ${MOREDEPS}"
>
> (qemuall is an override that is enabled by all qemu machines)

Another alternative would be something like:

IMAGE_INSTALL_remove_qemuall = "package_b"

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

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

[yocto] [PATCH][yocto-docs] distrodata: Add documentation about usage distrodata/checkpkg.

[Aníbal Limón]

[YOCTO #7894]

Signed-off-by: Aníbal Limón 
---
 documentation/ref-manual/ref-classes.xml | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/documentation/ref-manual/ref-classes.xml 
b/documentation/ref-manual/ref-classes.xml
index 9625894..ab6d3d3 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -728,6 +728,25 @@
  INHERIT+= "distrodata"
 
 
+
+
+   Two tasks are provided for the distrodata class distrodata and checkpkg,
+   this two tasks can be used against a simple recipe or a image one for
+   get all the recipes information of an image.
+
+   The task distrodata provides information about the recipe and the 
checkpkg
+   provides the same information as distrodata plus upstream 
version/status that
+   means what version of the software exists in upstream and if is 
un-updated/updated/
+   unknown.
+
+
+
+For execute distrodata/checkpkg over an image:
+
+   $ bitbake core-image-minimal -c distrodata
+
+   The results are stored in $LOG_DIR by default $BUILD_DIR/tmp/log.
+
 
 
 
-- 
2.1.4

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

[yocto] Possible introspection failure in master

[Chris Tapp]

I’m trying to build gstreamer1.0-plugins-base_git.bb under master. Compilation 
is failing with:

| g-ir-scanner: link: ../../../libtool --mode=link --tag=CC 
x86_64-poky-linux-gcc -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 
--sysroot=/media/SSD-Build/build-jethro-opty4-v2/tmp/sysroots/valleyisland-64 
-o 
/media/SSD-Build/build-jethro-opty4-v2/tmp/work/corei7-64-poky-linux/gstreamer1.0-plugins-base/1.7.2+gitAUTOINC+97e108beba-r0/build/gst-libs/gst/fft/tmp-introspectIeb9nD/GstFft-1.0
 -export-dynamic -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/media/SSD-Build/build-jethro-opty4-v2/tmp/work/corei7-64-poky-linux/gstreamer1.0-plugins-base/1.7.2+gitAUTOINC+97e108beba-r0/build=/usr/src/gstreamer1.0-plugins-base
 
-fdebug-prefix-map=/media/SSD-Build/build-jethro-opty4-v2/tmp/work/corei7-64-poky-linux/gstreamer1.0-plugins-base/1.7.2+gitAUTOINC+97e108beba-r0/git=/usr/src/gstreamer1.0-plugins-base
 
-fdebug-prefix-map=/media/SSD-Build/build-jethro-opty4-v2/tmp/sysroots/x86_64-linux=
 
-fdebug-prefix-map=/media/SSD-Build/build-jethro-opty4-v2/tmp/sysroots/valleyisland-64=
 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
tmp-introspectIeb9nD/media/SSD-Build/build-jethro-opty4-v2/tmp/work/corei7-64-poky-linux/gstreamer1.0-plugins-base/1.7.2+gitAUTOINC+97e108beba-r0/build/gst-libs/gst/fft/tmp-introspectIeb9nD/GstFft-1.0.o
 -L. libgstfft-1.0.la -lgio-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread 
-lgstreamer-1.0 -lgobject-2.0 -lglib-2.0
| Caught exception:  OSError(2, 'No such file or 
directory')
| > 
/media/SSD-Build/build-jethro-opty4-v2/tmp/sysroots/x86_64-linux/usr/lib/python2.7/subprocess.py(1335)_execute_child()
| -> raise child_exception
| (Pdb)

I’ve tried removing tmp/ and cleansstate but this didn’t help.

I’m not sure what to try next. Any pointers?

--

Chris Tapp
opensou...@keylevel.com
www.keylevel.com


You can tell you're getting older when your car insurance gets real cheap!



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

Re: [yocto] Re: Qt5.6 new modules

[idealsim]

Hi, i have started a build of the image this master Branch, like you 
said i have an error on qtserialbus :


/WARNING: Failed to fetch URL 
git://github.com/qtproject/qtserialbus.git;name=qtserialbus;branch=5.6;protocol=git, 
attempting MIRRORS if available//
//ERROR: Fetcher failure: Unable to find revision 
6a16281aceedb713676e16c3074e6f7ea1e70b79 in branch 5.6 even from upstream//
//ERROR: Function failed: Fetcher failure for URL: 
'git://github.com/qtproject/qtserialbus.git;name=qtserialbus;branch=5.6;protocol=git'. 
Unable to fetch URL from any source.//
//ERROR: Logfile of failure stored in: 
/media/modjo/data1TO/yocto/seco/udoo-community-bsp/neoBuild/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtserialbus/5.5.99+5.6.0-rc+gitAUTOINC+6a16281ace-r0/temp/log.do_fetch.5862//
//ERROR: Task 894 
(/media/modjo/data1TO/yocto/seco/udoo-community-bsp/sources/meta-qt5/recipes-qt/qt5/qtserialbus_git.bb, 
do_fetch) failed with exit code '1'/


This is my /qtserialbus_git.bb :

//require qt5.inc//
//require qt5-git.inc//
//
//# There are no LGPLv3-only licensed files in this component.//
//# There are no GPLv2 licensed files in this component.//
//LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 & 
The-Qt-Company-Qt-LGPL-Exception-1.1 | LGPL-3.0)"//

//LIC_FILES_CHKSUM = " \//
//file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \//
//file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \//
//file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \//
//file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \//
//"//
//
//DEPENDS += "qtbase qtserialport"//
//
//SRCREV = "6a16281aceedb713676e16c3074e6f7ea1e70b79"//

/An idea is welcome !

Regards,

Mickaël



Le 16/03/2016 14:57, idealsim a écrit :

Thanks for the tip. I will try it out and let you know ...

Regards,

Mickaël

Le 16/03/2016 10:17, Christian Ege a écrit :

Hi,,

2016-03-16 9:04 GMT+01:00 idealsim :
Hi, we have build an image for udoo neo from meta-qt5 
jansa/master-5.6 and
works fine (thanks to Christian Ege ). The problem is that I'm 
looking for

https://github.com/qtproject/qtquickcontrols2 and
https://github.com/qtproject/qtserialbus. My question is how we can 
add this

modules to our build ?  I add this to our local.conf :

 "qtquickcontrols2 \
  qtserialbus \
 "
But this modules don't have buildable providers ! If someone can 
help to

said me how to proceed ...

You can try to add a meta-qt5/recipes-qt/qt5/qtserialbus_git.bb and
take for example meta-qt5/recipes-qt/qt5/qtsensors_git.bb as reference

require qt5.inc
require qt5-git.inc
# There are no LGPLv3-only licensed files in this component.
# There are no GPLv2 licensed files in this component.
LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 &
The-Qt-Company-Qt-LGPL-Exception-1.1 | LGPL-3.0)"
LIC_FILES_CHKSUM = " \
file://LICENSE.LGPLv21;md5=58a180e1cf84c756c29f782b3a485c29 \
file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
file://LGPL_EXCEPTION.txt;md5=9625233da42f9e0ce9d63651a9d97654 \
file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \
file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
"
DEPENDS += "qtbase"

SRCREV = "71a323e1f12df8d213a4052621027e223eb5a343"

The configure step will bail out due to the fact that you have wrong
checksums but it will show you the right ones

Best,
Christian



regards,

Mickael


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







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

[yocto] Yocto Project Status WW12

[Jolley, Stephen K]

Current Dev Position: YP 2.1 M4 (Stabilization only milestone.)

Next Deadline: YP 2.1 M3 Target release date is March 18, 2016 (Will be late, 
see status)


SWAT team rotation: Maxin -> Joshua

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


Key Status/Updates:

*The M3 build occurred and has been passed to QA. Most things that were 
planned were included. We did end up disabling prelink for now as we don't know 
when we'll figure out how to properly fix the IFUNC issues we ran into there.

*QA on M3 is still continuing but there is a known issue with toaster 
startup. We'd likely not do a complete respin just for this issue but just 
retest toaster.

*There continue to be several build race issues and other problems 
which are being worked on.

*The number of bugs coming into the bugzilla is very high and putting a 
lot of pressure on the team which means the WDD is likely to rise significantly 
next week.

*On a personal note, it looks like I won't be able to attend ELC 
partially due to limited availability of travel funds.


Key YP 2.1 Dates:

YP 2.1 M3 Target release date is March 18, 2016 (Will be late, see status)

YP 2.1 M4 / Final Cutoff: March 28, 2016 noon GMT - Stabilization only 
milestone.

YP 2.1 Final Release Target: April 29, 2016


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.1_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.1_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.1_Features


Tracking Metrics:

WDD 2616 (last week 2628)

(https://wiki.yoctoproject.org/charts/combo.html)

[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]

Thanks,

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

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

[yocto] Installing the SDKs made with meta-mingw

[Matt Hoosier]

Hi,

I've successfully built a Canadian-cross SDK using the meta-mingw layer.
Very nice!

Because the layer lobotomizes the SDK_PACKAGING_FUNC when ${SDKMACHINE} is
set to a MinGW host, though, the resulting SDK is not encapsulated into the
self-extracting tarball and the corresponding relocation logic (
relocate_sdk.py and so forth) is omitted.

Any suggestions on how to do the last-mile work to use the SDK on Windows?
Or perhaps nothing is needed at all, except adjusting the prefixes built
into environment-setup-? Although that would be nice, I think at
least some installation-time adjustment is necessary though; when I do:

arm-poky-linux-gnueabi-gcc -o foo foo.c
--sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi

, the following happens during linking:

ld.exe: cannot find /lib/libc.so.6 inside
d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi

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

Re: [yocto] use yocto toolchain as external toolchain

[Gary Thomas]

On 03/17/2016 12:40 PM, gm...@reliableembeddedsystems.com wrote:

Hi,

It may sound slightly crazy:) but can I use a toolchain, which was created by 
Poky as an external toolchain for Poky?

What I am after is something like this:

I create a multiplatfrom v7 compatible Yocto project, which spits out 
toolchain/rootfs/kernel/various device trees.[1]

Now I need to build for each board a custom u-boot, something like [2][3],...

Obviously [2] and [3] build again the toolchain. Would it be possible to reuse 
the toolchain built by [1] like an
external toolchain to save some build time?

Regards,

Robert


[1] 
https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.4.x/multi-v7-ml
[2] 
https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.4.x/beagle-bone-black-multi-v7-ml
[3] 
https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.4.x/zedboard-multi-v7-ml


No need for an external toolchain.  Simply point builds [2] & [3]
to the sstate-cache from build [1].  This will allow sharing of
much of the build, certainly the toolchain, with the subsequent
builds.  Modify your local.conf to include these lines:
  # Reusable state information
  SSTATE_MIRRORS ?= "\
  file://.* file:///BUILD1/sstate-cache/PATH"
(of course set BUILD1 to the actual path of your build tree)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Not able to disable introspection in gstreamer

[alexander . kanavin]

> I am trying to build latest poky version from upstream but it was failing
> in "gobject-introspection-data?".
>
> I disabled it with comments mentioned in:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?id=8c14c746da1784c4bdaa621dde6fccd99e72ef1b
>
>
> by adding folloing line in config:
>
> MACHINE_FEATURES_BACKFILL_CONSIDERED = "gobject-introspection-data"
>
>
> Now gstreamer is throwing error for introspection.

Your log seems to say that gstreamer is at 1.6.0, and therefore is coming
from some other layer than oe-core (which has 1.6.3). Disabling
introspection in recipes by using MACHINE_FEATURES_BACKFILL_CONSIDERED
only works if those recipes inherit gobject-introspection class, and so
this is what you should do. Or migrate from your custom gstreamer recipes
to ones provided by oe-core, and then you don't have to disable anything
at all most likely, and you will gain ability to use gstreamer from Python
scripts, Vala or other runtimes.

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

Re: [yocto] Qt5.6 new modules

[idealsim]

Thanks for the tip. I will try it out and let you know ...

Regards,

Mickaël

Le 16/03/2016 10:17, Christian Ege a écrit :

Hi,,

2016-03-16 9:04 GMT+01:00 idealsim :

Hi, we have build an image for udoo neo from meta-qt5 jansa/master-5.6 and
works fine (thanks to Christian Ege ). The problem is that I'm looking for
https://github.com/qtproject/qtquickcontrols2 and
https://github.com/qtproject/qtserialbus. My question is how we can add this
modules to our build ?  I add this to our local.conf :

 "qtquickcontrols2 \
  qtserialbus \
 "
But this modules don't have buildable providers ! If someone can help to
said me how to proceed ...

You can try to add a meta-qt5/recipes-qt/qt5/qtserialbus_git.bb and
take for example meta-qt5/recipes-qt/qt5/qtsensors_git.bb as reference

require qt5.inc
require qt5-git.inc
# There are no LGPLv3-only licensed files in this component.
# There are no GPLv2 licensed files in this component.
LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 &
The-Qt-Company-Qt-LGPL-Exception-1.1 | LGPL-3.0)"
LIC_FILES_CHKSUM = " \
file://LICENSE.LGPLv21;md5=58a180e1cf84c756c29f782b3a485c29 \
file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
file://LGPL_EXCEPTION.txt;md5=9625233da42f9e0ce9d63651a9d97654 \
file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \
file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
"
DEPENDS += "qtbase"

SRCREV = "71a323e1f12df8d213a4052621027e223eb5a343"

The configure step will bail out due to the fact that you have wrong
checksums but it will show you the right ones

Best,
Christian



regards,

Mickael


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





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

Re: [yocto] [PATCH 1/3][eclipse-poky][mars] systemtap: Add button to browse to build folder.

[Jose Lamego]

Ping

On 03/09/2016 05:22 PM, Jose Lamego wrote:
> From: Adrian Dudau 
> 
> Fixes [Yocto 4423]
> Porting commit a80114b5d1c8d774fd9271da48a38654321d4817 from
> the Juno branch.
> 
> Signed-off-by: Jose Lamego 
> ---
>  .../src/org/yocto/remote/utils/ShellSession.java   |  6 +++--
>  .../src/org/yocto/sdk/remotetools/Messages.java|  1 +
>  .../sdk/remotetools/actions/SystemtapHandler.java  |  3 ++-
>  .../sdk/remotetools/actions/SystemtapModel.java|  5 ++--
>  .../actions/SystemtapSettingDialog.java| 28 
> ++
>  .../org/yocto/sdk/remotetools/messages.properties  |  3 ++-
>  6 files changed, 40 insertions(+), 6 deletions(-)
> 
> diff --git 
> a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java 
> b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java
> index 4ac8001..2a4dbf5 100644
> --- 
> a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java
> +++ 
> b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java
> @@ -46,6 +46,7 @@ public class ShellSession {
>   private String shellPath = null;
>   private final String initCmd;
>   private final File root;
> +private final File builddir;
>  
>   private OutputStreamWriter out;
>  
> @@ -68,8 +69,9 @@ public class ShellSession {
>   return sb.toString();
>   }
>  
> - public ShellSession(int shellType, File root, String initCmd, 
> OutputStream out) throws IOException {
> + public ShellSession(int shellType, File root, File builddir, String 
> initCmd, OutputStream out) throws IOException {
>   this.root = root;
> +this.builddir = builddir;
>   this.initCmd  = initCmd;
>   if (out == null) {
>   this.out = new OutputStreamWriter(null);
> @@ -93,7 +95,7 @@ public class ShellSession {
>   }
>  
>   if (initCmd != null) {
> - execute("source " + initCmd);
> + execute("source " + initCmd + " " + 
> builddir.getAbsolutePath());
>   }
>   }
>  
> diff --git 
> a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
>  
> b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
> index 093118d..16f5dc8 100644
> --- 
> a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
> +++ 
> b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
> @@ -40,6 +40,7 @@ public class Messages extends NLS {
>   public static String TerminalViewer_text;
>   //public static String Systemtap_KO_Text;
>   public static String Metadata_Location;
> +public static String Builddir_Location;
>   public static String User_ID;
>   public static String Remote_User_ID;
>   public static String Remote_Host;
> diff --git 
> a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
>  
> b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
> index 79048aa..86c963f 100644
> --- 
> a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
> +++ 
> b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
> @@ -53,6 +53,7 @@ public class SystemtapHandler extends AbstractHandler {
>   if(setting.open() == BaseSettingDialog.OK) {
>  
>   String metadata_location = 
> ((SystemtapSettingDialog)setting).getMetadataLocation();
> +String builddir_location = 
> ((SystemtapSettingDialog)setting).getBuilddirLocation();
>   String remote_host = 
> ((SystemtapSettingDialog)setting).getRemoteHost();
>   String user_id = 
> ((SystemtapSettingDialog)setting).getUserID();
>   String systemtap_script = 
> ((SystemtapSettingDialog)setting).getSystemtapScript();
> @@ -66,7 +67,7 @@ public class SystemtapHandler extends AbstractHandler {
>   if (terminalSubSystem != null) {
>   TerminalsUI terminalsUI = 
> TerminalsUI.getInstance();
>   TerminalViewer terminalViewer = 
> terminalsUI.activateTerminalsView();
> - SystemtapModel op = new 
> SystemtapModel(metadata_location,remote_host, user_id, systemtap_script,
> + SystemtapModel op = new 
> SystemtapModel(metadata_location,builddir_location,remote_host, user_id, 
> systemtap_script,
>   
> systemtap_args,window.getShell().getDisplay());
>   try {
>   op.setHost(host);
> diff --git 
> 

[yocto] [yocto-autobuilder][PATCH] buildbot/templates: Fix link to error reporting tool

[Michael Wood]

Fix link so that we don't perform a full text search for the
SHA/revision and just filter for it using the commit field. This should
drastically reduce page loading time on the error reporting site.

[YOCTO #9295]

Signed-off-by: Michael Wood 
---
 .../buildbot/status/web/templates/grid_macros.html  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/web/templates/grid_macros.html
 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/web/templates/grid_macros.html
index 0479927..8876422 100644
--- 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/web/templates/grid_macros.html
+++ 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/web/templates/grid_macros.html
@@ -26,7 +26,7 @@
   {%- else %}Commit: latest{% endif %}
   {%- if ss.branch %} in {{ ss.branch|e }}{% endif %}
   {%- if ss.hasPatch %} [patch]{% endif -%}
-  (http://errors.yoctoproject.org/Errors/Search/Args/?items=10={{ss.revision}};>errors)
+  (http://errors.yoctoproject.org/Errors/Latest/Autobuilder/?filter={{ss.revision}}=commit;>errors)
 
 {%- endfor %}
   
-- 
2.5.0

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

[yocto] [PATCH][meta-cgl] ocfs2-tools: uprev to 1.8.4

[rongqing.li]

From: Roy Li 

1. 1.8.4 asks libaio
2. remove 0002-ocfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch
which has been merged into 1.8.4
3. remove the host contamination by replacing the host related path
in do_configure_prepend
4. add bash into RDEPENDS, since /etc/init.d/ocfs2 and /etc/init.d/o2cb
are the bash scripts

Signed-off-by: Roy Li 
---
 ...cfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch | 29 --
 .../{ocfs2-tools_1.6.4.bb => ocfs2-tools_1.8.4.bb} | 28 -
 2 files changed, 22 insertions(+), 35 deletions(-)
 delete mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0002-ocfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch
 rename meta-cgl-common/recipes-cgl/ocfs2-tools/{ocfs2-tools_1.6.4.bb => 
ocfs2-tools_1.8.4.bb} (77%)

diff --git 
a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0002-ocfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch
 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0002-ocfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch
deleted file mode 100644
index f07cdab..000
--- 
a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/0002-ocfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From 507f5cf55e25fd12d138cc28eb061c7e0b8615b8 Mon Sep 17 00:00:00 2001
-From: Li xin 
-Date: Fri, 12 Dec 2014 16:14:10 +0900
-Subject: [PATCH 2/3] ocfs2_fs.h mount.ocfs2.c: fix compile error
-
-Upstream-Status: pending
-
-Signed-off-by: Li Xin 

- include/ocfs2-kernel/ocfs2_fs.h | 2 +-
- mount.ocfs2/mount.ocfs2.c   | 4 +++-
- 2 files changed, 4 insertions(+), 2 deletions(-)
-
-diff --git a/include/ocfs2-kernel/ocfs2_fs.h b/include/ocfs2-kernel/ocfs2_fs.h
-index 2140bb3..00add7b 100644
 a/include/ocfs2-kernel/ocfs2_fs.h
-+++ b/include/ocfs2-kernel/ocfs2_fs.h
-@@ -1311,7 +1311,7 @@ static inline int ocfs2_sprintf_system_inode_name(char 
*buf, int len,
- }
- 
- static inline void ocfs2_set_de_type(struct ocfs2_dir_entry *de,
--  umode_t mode)
-+   unsigned short mode)
- {
-   de->file_type = ocfs2_type_by_mode[(mode & S_IFMT)>>S_SHIFT];
- }
--- 
-1.8.4.2
-
diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.6.4.bb 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
similarity index 77%
rename from meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.6.4.bb
rename to meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
index acc8379..18ef563 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.6.4.bb
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
@@ -12,20 +12,18 @@ SECTION = "System Environment/Base"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
-SRC_URI = " \
-https://oss.oracle.com/projects/${BPN}/dist/files/source/v1.6/${BP}.tar.gz 
\
-file://0002-ocfs2_fs.h-mount.ocfs2.c-fix-compile-error.patch \
+SRC_URI = "git://oss.oracle.com/git/ocfs2-tools.git \
 file://0003-vendor-common-o2cb.ocf-add-new-conf-file.patch \
 file://cluster.conf.sample \
 file://o2cb.service \
 file://ocfs2.service \
 "
-SRC_URI[md5sum] = "2e94423507b63fcc08f93c094e789be8"
-SRC_URI[sha256sum] = 
"dda9db208312e3e5f4f55ee77e66e7b35b9cc10421bc02065a6c168e42b24755"
+SRCREV = "0b8be47d61dbdcd08d21c83f0b3993735b884ef9"
+S = "${WORKDIR}/git"
 
 inherit autotools-brokensep pkgconfig systemd
 
-DEPENDS = "corosync openais cluster-glue pacemaker libxml2 linux-libc-headers 
e2fsprogs"
+DEPENDS = "corosync openais cluster-glue pacemaker libxml2 linux-libc-headers 
e2fsprogs libaio"
 RDEPENDS_${PN} = "bash coreutils net-tools module-init-tools e2fsprogs 
chkconfig glib-2.0"
 ASNEEDED_pn-${PN} = ""
 PARALLEL_MAKE = ""
@@ -38,6 +36,22 @@ EXTRA_OECONF = " \
 --enable-dynamic-fsck=yes \
 --enable-dynamic-ctl=yes \
 "
+
+do_configure_prepend () {
+# fix here or EXTRA_OECONF
+sed -i -e '/^PYTHON_INCLUDES="-I/c\
+PYTHON_INCLUDES="-I=/usr/include/python${PYTHON_BASEVERSION}"' \
+${S}/pythondev.m4
+sed -i  -e 
's:PYTHON_PREFIX/lib/python:PYTHON_PREFIX/${baselib}/python:' \
+-e 
's:PYTHON_EXEC_PREFIX}/lib/python:PYTHON_EXEC_PREFIX}/${baselib}/python:' \
+${S}/python.m4
+
+# fix the AIS_TRY_PATH which will search corosync|openais
+# AIS_TRY_PATH=":/usr/lib64/:/usr/lib:/usr/local/lib64:/usr/local/lib"
+sed -i -e '/^AIS_TRY_PATH=":\/usr\/lib64:/s;:;:=;g' ${S}/configure.in
+}
+
+
 do_compile_prepend() {
 for m in `find . -name "Makefile"` ; do
 sed -i -e "s@-I/usr/include@-I${STAGING_DIR_TARGET}/usr/include@g" $m
@@ -73,3 +87,5 @@ do_install() {
 install -m 755 vendor/common/o2cb.init ${D}/${libexecdir}/o2cb-helper
 fi
 }
+
+RDEPENDS_${PN} = "bash"
-- 
1.9.1

-- 
___
yocto mailing list

Re: [yocto] Not able to disable introspection in gstreamer

[Burton, Ross]

On 16 March 2016 at 16:13, Martin Jansa  wrote:

> I think it's because COMBINED_FEATURES conditional is used only to add
> --enable-introspection in EXTRA_OECONF, but other changes like
> introspection.m4 changes are done in all builds.
>

Then the class should be passing --disable-introspection. Is the problem
also that your recipes are not inheriting this class, so they're
auto-detecting pieces of the GIR framework?

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

Re: [yocto] Not able to disable introspection in gstreamer

[Ashish Shrivastava]

DEBUG: SITE files ['endian-little', 'bit-32', 'mips-common', 'common-linux', 
'common-glibc', 'mipsel-linux', 'common']
DEBUG: Executing shell function do_compile
NOTE: make -j 8
make  all-recursive
make[1]: Entering directory 
`/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/work/mips32r2el-nf-poky-linux/gstreamer1.0-plugins-base/1.6.0-r0/build'
Making all in pkgconfig
make[2]: Entering directory 
`/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/work/mips32r2el-nf-poky-linux/gstreamer1.0-plugins-base/1.6.0-r0/build/pkgconfig'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory 
`/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/work/mips32r2el-nf-poky-linux/gstreamer1.0-plugins-base/1.6.0-r0/build/pkgconfig'
Making all in gst-libs
make[2]: Entering directory 
`/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/work/mips32r2el-nf-poky-linux/gstreamer1.0-plugins-base/1.6.0-r0/build/gst-libs'
Making all in gst
make[3]: Entering directory 
`/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/work/mips32r2el-nf-poky-linux/gstreamer1.0-plugins-base/1.6.0-r0/build/gst-libs/gst'
make -C tag
make -C fft
make -C sdp
make -C video
make -C app
make[4]: Entering directory 
`/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/work/mips32r2el-nf-poky-linux/gstreamer1.0-plugins-base/1.6.0-r0/build/gst-libs/gst/sdp'
../../../mipsel-poky-linux-libtool  --tag=CC   --mode=link 
mipsisa32r2el-axis-linux-gnu-gcc  -mel -mabi=32 -msoft-float -march=mips32r2 
--sysroot=/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775
 -std=gnu99 -I../../../../gst-plugins-base-1.6.0/gst-libs -I../../../gst-libs 
-pthread 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/include/gstreamer-1.0
 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/lib/gstreamer-1.0/include
 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/include/glib-2.0
 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/lib/glib-2.0/include
 -pthread 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/include/glib-2.0
 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/lib/glib-2.0/include
 -pthread 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/include/gstreamer-1.0
 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/lib/gstreamer-1.0/include
 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/include/glib-2.0
 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/lib/glib-2.0/include
 -DG_THREADS_MANDATORY -DG_DISABLE_CAST_CHECKS -DG_DISABLE_ASSERT -Wall 
-Wdeclaration-after-statement -Wvla -Wpointer-arith -Wmissing-declarations 
-Wmissing-prototypes -Wredundant-decls -Wundef -Wwrite-strings 
-Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs 
-Waddress -Waggregate-return -Wno-multichar -Wnested-externs -Wno-unused   
-pthread 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/include/glib-2.0
 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/lib/glib-2.0/include
 -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/work/mips32r2el-nf-poky-linux/gstreamer1.0-plugins-base/1.6.0-r0/build=/usr/src/gstreamer1.0-plugins-base
 
-fdebug-prefix-map=/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/work/mips32r2el-nf-poky-linux/gstreamer1.0-plugins-base/1.6.0-r0/gst-plugins-base-1.6.0=/usr/src/gstreamer1.0-plugins-base
 
-fdebug-prefix-map=/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/x86_64-linux=
 
-fdebug-prefix-map=/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775=
  -export-symbols-regex ^_?\(gst_\|Gst\|GST_\).* -no-undefined 
-Wl,-Bsymbolic-functions -version-info 600:0:600 -Wl,-O1  -Wl,--as-needed -o 
libgstsdp-1.0.la -rpath /usr/lib libgstsdp_1.0_la-gstsdpmessage.lo 
libgstsdp_1.0_la-gstmikey.lo -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0  
-lgio-2.0 -lgobject-2.0 -lglib-2.0 
make[4]: Entering directory 
`/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/work/mips32r2el-nf-poky-linux/gstreamer1.0-plugins-base/1.6.0-r0/build/gst-libs/gst/tag'
../../../mipsel-poky-linux-libtool  --tag=CC   --mode=link 
mipsisa32r2el-axis-linux-gnu-gcc  -mel -mabi=32 -msoft-float -march=mips32r2 
--sysroot=/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775
 -std=gnu99 -I../../../../gst-plugins-base-1.6.0/gst-libs -I../../../gst-libs 
-pthread 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/include/gstreamer-1.0
 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/lib/gstreamer-1.0/include
 
-I/home/ashishs/dists/jangal-poky-master/builds/q1775/tmp/sysroots/q1775/usr/include/glib-2.0
 

Re: [yocto] Conditional compile for package in layer.conf for Qemu

[Andre McCurdy]

On Wed, Mar 16, 2016 at 2:01 AM, Burton, Ross  wrote:
>
> On 16 March 2016 at 08:56, Mark T  wrote:
>>
>> I'd like to be able to do the following
>>
>> IMAGE_INSTALL_append += "package_a"

It's not typical usage to combine += with _append, pick one or the other.

Using _append is generally more reliable if you're not sure how the
variable you're appending to was originally initialised, however with
_append you need to manually include a leading space character, ie:

IMAGE_INSTALL_append = " package_a"

>> if ( not qemu )
>> IMAGE_INSTALL_append += "package_b"
>> endif
>
>
> The neater way would be if you can easily identify what "not qemu" is, for
> example:
>
> IMAGE_INSTALL_append_intel-corei7-64 = "package_b"
>
> Would install package_b only for intel-corei7-64 machines.
>
> If you want to support arbitrary machines but not qemu then something like
> this might work:
>
> MOREDEPS = "package_b"
> MOREDEPS_qemuall = ""
> IMAGE_INSTALL_append = " ${MOREDEPS}"
>
> (qemuall is an override that is enabled by all qemu machines)

Another alternative would be something like:

IMAGE_INSTALL_remove_qemuall = "package_b"

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

[yocto] use yocto toolchain as external toolchain

[gmane]

Hi,

It may sound slightly crazy:) but can I use a toolchain, which was 
created by Poky as an external toolchain for Poky?


What I am after is something like this:

I create a multiplatfrom v7 compatible Yocto project, which spits out 
toolchain/rootfs/kernel/various device trees.[1]


Now I need to build for each board a custom u-boot, something like 
[2][3],...


Obviously [2] and [3] build again the toolchain. Would it be possible to 
reuse the toolchain built by [1] like an external toolchain to save some 
build time?


Regards,

Robert


[1] 
https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.4.x/multi-v7-ml
[2] 
https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.4.x/beagle-bone-black-multi-v7-ml
[3] 
https://github.com/RobertBerger/meta-mainline/tree/jethro-training-v4.4.x/zedboard-multi-v7-ml

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

Re: [yocto] hddimg vs hdddirect?

[K Richard Pixley]

On 3/16/16 21:37 , Gary Thomas wrote:

On 03/16/2016 08:40 PM, K Richard Pixley wrote:

What's the intended difference between hddimg and hdddirect?

I'm confused about the intent here. The data flow in previous releases,
even jethro, seems to be somewhat confused/broken so looking at the
source code isn't really helping here.

Is one intended to be a simple syslinux bootable image while the other
is a "live" image with multiple boot choices?

In master... How does one go about requesting either a vmdk of a live
image or a directly bootable vmdk?


I'm not sure the difference between the .hddimg and .hdddirect.
I tried converting a .hddimg to .vdi or .vmdk using the VBoxManage
tool, but that didn't come up - there was a message about (paraphrased)
"waiting for removable media to become ready"  and the boot just hung up

However, I do know that .vmdk will boot easily with VirtualBox
Just add this to your local.conf
  IMAGE_FSTYPES += " vmdk"

Note: as mentioned in the documentation, you must use += as
IMAGE_FSTYPES_append will not do.
That hasn't worked for me yet on any branch I've tried.  Some build.  
None boot even past syslinux.  A variety of errors.


That's why I'm asking about intent and/or design.  If there's a plan, 
perhaps I can chip in.  But perhaps there is no concerted effort nor 
well known plan, in which case I can probably invent one if I can 
appreciate the relevant contexts.


In particular, *which* hdd should vmdk be an image of?  hddimg, (which 
builds and boots prior to master), or hdddirect, (which doesn't boot for 
me at all so I don't even know what it's intended to do)?  How do I get 
the old, single syslinux boot target hddimg, (the one that works), out 
of master?


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

[yocto] Upgrade from Daisy to Jethro -> Hardware Problems (Device Tree)

[Ruben Schwarz]

Hi,

we have a customized hardware based on Beaglebone Black. We created an BSP
Layer with daisy and everything worked fine.

Now we decided to upgrade our yocto sources from daisy (Kernel 3.14.4) to
jethro (Kernel 4.1.15).

I adjusted the Kernel patches to work with new sources. The system boots
but the network interfaces aren't available.
ip a shows only the loopback interface.

I see that the Kernel Image changed from uImage to zImage. Device Tree
files are used as an the previous build.

Does anybody know if I have to change the device tree files to work with
the new Kernel? Any other ideas how to solve this problem?

Best regards
Ruben

-- 


Besuchen Sie unseren Chrome Webshop unter shop.cloudwuerdig.com

www.sotec.eu | www.cloudwuerdig.com 
-- 
SOTEC Software Entwicklungs GmbH + Co Mikrocomputertechnik KG 
Calwer Straße 11, D-75395 Ostelsheim 
Sitz Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664, 
Geschäftsführer: Florian Holz 
Cloudwürdig® ist eine eingetragene Marke der SOTEC Software Entwicklungs 
GmbH + Co Mikrocomputertechnik KG

Der Inhalt dieser e-Mail ist ausschließlich für den bezeichneten Adressaten 
bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser e-Mail oder dessen 
Vertreter sein sollten, so beachten Sie bitte, dass jede Form der 
Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des 
Inhalts dieser e-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall 
mit dem Absender der e-Mail in Verbindung zu setzen.

The content of this e-mail is meant exclusively for the person to whom it 
is addressed. If you are not the person to whom this e-mail is addressed or 
his/her representative, please be informed, that any form of knowledge, 
publication, duplication or distribution of the content of this e-mail is 
inadmissible. We ask you, therefore, in such a case to please contact the 
sender of this e-mail.

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

Re: [yocto] Compiling raspberry2 with eglinfo-x11

[David Weisgerber]

Hi,
I got Qt to compile by solving the following "problem" in the userland EGL / 
GLESv2 code:
# Khronos
#
# Note: in Android the linker is unable or unwilling to resolve
# dynamically using already loaded symbols. The libraries here
# have quite a few circular dependencies, and so the only way
# to make it work seems to be to have everything static.

There is a circular dependency between libEGL and libGLESv2. You can fix the 
Qt compile by adding the following qtbase_%.bbappend:
do_configure_prepend_rpi() {
cat > ${S}/mkspecs/oe-device-extra.pri << 'EOF'
EGLFS_DEVICE_INTEGRATION = eglfs_brcm
QMAKE_INCDIR_EGL = $$[QT_SYSROOT]${includedir}/interface/vmcs_host/linux
QMAKE_INCDIR_OPENGL_ES2 = $${QMAKE_INCDIR_EGL}
QMAKE_LIBS_EGL = -lEGL -lGLESv2
EOF
}

which just changes the order of linking to the libraries.

However, I am still not able to get the Qt eglfs programs running due to the 
following problem:
* failed to add service - already in use?
which must be coming from the userland code

My problem could be caused by the fact, that changing GPU_MEM does not seem to 
have any effect atm and the vc4 driver isn't loaded at startup...

Thanks for help,
David

On Thursday, March 17, 2016 12:41:17 PM SIVA SUBRAMANIAN. P wrote:
> What is your preferred GLES provider set to, userland or mesa?
> 
> On Wed, Mar 16, 2016 at 8:51 PM, David Weisgerber
> 
>  wrote:
> > Hi,
> > 
> > I have problems compiling eglinfo-x11 (as well as Qt 5 from meta-qt5) with
> > egl.
> > 
> > I have setup poky, meta-raspberrypi (and meta-qt5) from git and I am on
> > branch master.
> > 
> > My target is to get a distribution with working (hw acceleratetd) Qt5 with
> > QML GUI. I have already spent some days on getting qteverywheredemo
> > running
> > but I did not succeed yet.
> > 
> > As a first test I wanted to get eglinfo-x11 running but it gives the
> > following error when compiling:
> > 
> > [11/11] cxxprogram: build/release/src/json_writer.cpp.1.o
> > build/release/src/log.cpp.1.o build/release/src/main.cpp.1.o
> > build/release/src/process_egl.cpp.1.o build/release/src/scopes.cpp.1.o
> > build/release/src/text_writer.cpp.1.o
> > build/release/src/json-sax/json.c.1.o
> > b
> > uild/release/src/platform_x11_generic.cpp.1.o
> > build/release/src/openvg_stats.cpp.1.o
> > build/release/src/process_openvg.cpp.1.o -> build/release/eglinfo
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glDiscardFramebufferEXT'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glPointSizePointerOES'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_set_error_api'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_BindFramebuffer'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glintAttribPointer'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_state_free'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_FramebufferRenderbuffer'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_buffer_info_set'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_set_error'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_DeleteFramebuffers'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `gl11_client_state_init'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_GetFramebufferAttachmentParameteriv'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_IsRenderbuffer'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_GetRenderbufferParameteriv'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_DeleteRenderbuffers'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glBufferSubData'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_FramebufferTexture2D'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_BindRenderbuffer'
> > /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> > undefined reference to `glxx_client_GenerateMipmap'
> > 

[yocto] hddimg vs hdddirect?

[K Richard Pixley]

What's the intended difference between hddimg and hdddirect?

I'm confused about the intent here. The data flow in previous releases,
even jethro, seems to be somewhat confused/broken so looking at the
source code isn't really helping here.

Is one intended to be a simple syslinux bootable image while the other
is a "live" image with multiple boot choices?

In master... How does one go about requesting either a vmdk of a live
image or a directly bootable vmdk?

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

Re: [yocto] [master] ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot:

[Christian Ege]

Hi,
On 16.03.2016 20:44, Martin Jansa wrote:
> Delete your TMPDIR and start again.
thx, this did the trick

Best,
Christian
> 
> On Wed, Mar 16, 2016 at 8:29 PM, Christian Ege  > wrote:
> 
> Hi,
> 
> with the latest master from today I ran in some trouble:
> 
> Build Configuration:
> BB_VERSION= "1.29.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "udooneo"
> DISTRO= "poky"
> DISTRO_VERSION= "2.0+snapshot-20160316"
> TUNE_FEATURES = "arm armv7a vfp thumb neon
> callconvention-hard   cortexa9"
> TARGET_FPU= "hard"
> meta
> meta-poky = "HEAD:8debfea81e69d038bd2d56314b272cb74f5582ed"
> meta-oe
> meta-multimedia
> meta-python
> meta-networking   = "HEAD:35d91f32c462ad5889cb3229766d6d4ed2c80a4c"
> meta-qt5  =
> "master-5.6:b2d5376b41625521b9a081fe800345fff33d8dd6"
> meta-ruby = "HEAD:35d91f32c462ad5889cb3229766d6d4ed2c80a4c"
> meta-fsl-arm  = "HEAD:37564e6801ce82fad979b4f57151c676d80e8a6c"
> meta-fsl-arm-extra = "HEAD:36a638abe1238bdc8e0ef1242dd7bfab59cc48d7"
> meta-fsl-demos= "HEAD:6b779b2cb0d231063fc035a9a0871d722366c329"
> meta-udoo = "master:1b38bcec5057b93017a00f107e0738ce64ade66f"
> meta-swupdate = "master:44516e81a494afef3be7e3f249713fdec6e6e32a"
> 
> NOTE: Preparing RunQueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot: The recipe
> gobject-introspection is trying to install files into a shared area
> when those files already exist. Those files and their manifest
> location are:
>  
>  
> /data/FSL/fsl-community-bsp-master/build/tmp/sysroots/udooneo/usr/share/gobject-introspection-1.0/Makefile.introspection
>  Matched in manifest-udooneo-gtk-doc-stub.populate_sysroot
>  
> /data/FSL/fsl-community-bsp-master/build/tmp/sysroots/udooneo/usr/share/aclocal/introspection.m4
>  Matched in manifest-udooneo-gtk-doc-stub.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: gobject-introspection-1.46.0-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: gobject-introspection-1.46.0-r0 do_populate_sysroot: Function
> failed: sstate_task_postfunc
> ERROR: Logfile of failure stored in:
> 
> /data/FSL/fsl-community-bsp-master/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gobject-introspection/1.46.0-r0/temp/log.do_populate_sysroot.16494
> ERROR: Task 1802
> 
> (/data/FSL/fsl-community-bsp-master/sources/poky/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
> ,
> do_populate_sysroot) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 4772 tasks of which 4742 didn't need to
> be rerun and 1 failed.
> No currently running tasks (4772 of 5254)
> 
> 
> Any help is appreciated.
> 
> Best,
> Christian
> 
> --
> http://ch.ege.io/
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 

-- 
___
yocto 

Re: [yocto] Compiling kernel 4.4

[Andre McCurdy]

On Wed, Mar 16, 2016 at 11:21 PM, SIVA SUBRAMANIAN.P  wrote:
> Hi,
> While compiling linux kernel 4.4 for 96boards, I'm getting below error
> even though openssl headers are available in sysroot path.
>
> |   HOSTCC  scripts/selinux/mdp/mdp
> | 
> /mnt/home/knagabhirava/hikey/build/tmp-glibc/work-shared/hikey/kernel-source/scripts/extract-cert.c:21:25:
> fatal error: openssl/bio.h: No such file or directory
> |  #include 
> |  ^
> | compilation terminated.
>
> ERROR: Task 6 
> (/mnt/home/knagabhirava/hikey/build/../meta-96boards/recipes-kernel/linux/linux-96boards_git.bb,
> do_compile) failed with exit code '1'

If extract-cert.c is being compiled with HOSTCC then the recipe should
probably depend on openssl-native (not openssl). Or maybe the
assumption is that openssl development libraries are installed on the
host (e.g. "apt-get install libssl-dev" for Debian based systems).

Either way, this isn't the right mailing list for meta-96boards questions...

> Any idea/pointers?
>
> Regards,
> Sivasubramanian
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto