Re: [yocto] [PATCH 0/4][layerindex-web] bug fix and performance improve

[Robert Yang]

Hi Ross,

On 04/18/2018 07:12 PM, Burton, Ross wrote:

On 18 April 2018 at 12:04, Robert Yang  wrote:

   fixup! update: don't stop on unsatisfied layer dependencies


Pretty sure this isn't what you intended.


Thanks, but this is intended, I used:

$ git commit --fixup=8dd24abf99578e3d2572062ca04dbeac4321b2ea

While the 8dd24abf99578e3d2572062ca04dbeac4321b2ea is made by Paul,
I use this way to specify what it fixes, I can update the subject line
if this is not acceptable.

// Robert



Ross


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

Re: [yocto] [PATCH 4/4] update_layer.py: move layer validation to update.py (Performance improve)

[Robert Yang]

Hi Paul,

On 04/19/2018 04:55 AM, Paul Eggleton wrote:

On Wednesday, 18 April 2018 11:04:33 PM NZST Robert Yang wrote:

The utils.setup_django() costs a lot of time, but both update.py and
update_layer.py calls it, so move layer validation from update_layer.py to
update.py to avoid calling update_layer.py when possible can save a lot of
time.


Unfortunately I still can't merge this, as mentioned earlier it breaks
handling older python 2-bound releases.


I think you're talking about the one that I sent a few months ago, but this
one is a completely new patch, that one moved tinfoil into update.py which
broke python2, but this patch doesn't, it doesn't touch anything about tinfo,
so it works when I switch from YP 2.0 -> 2.2 -> 2.4, and vice visa.

// Robert



Cheers,
Paul


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

Re: [yocto] Need Help for meta-qt5

[Zoran Stojsavljevic]

http://developer.toradex.com/knowledge-base/how-to-set-up-qt-creator-to-cross-compile-for-embedded-linux#contents
http://developer.toradex.com/knowledge-base/board-support-package/openembedded-(core)#Adding_the_Qt5_Layer

Hope this helps,
Zoran
___

On Wed, Apr 18, 2018 at 6:24 PM, Vincent Daanen
 wrote:
> Hi,
>
>
>
> I have to add Qt5 QtCore libs to my image. I know I must use meta-qt5 but as
> I’m not familiar with qt configuration, I simply do not know how to start !
>
> So can someone help me to configure meta-qt5 to simply build and add QtCore
> to my image ?
>
> Thank you
>
>
>
> Vincent
>
>
>
>
>
>
> --
> ___
> 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] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

[Måns Zigher]

Hi,

I am building with the SDK (not extensible) but it is also built as a
recipe when building an image. The recipe is inheriting cmake but it is
only in the image build that I am experiencing this problem which I
shouldn't since the cmake_do_configure should be called. I will try and run
bitbake -e on the recepie to see if I get any clear if the
cmake_do_configure is part of it or not.

Thanks for your time I appreciate it.

Br
Mans Zigher


On Wed, Apr 18, 2018, 22:47 Dennis Menschel  wrote:

> Hi Mans,
>
> Am 18.04.2018 um 06:56 schrieb Måns Zigher:
> > Hi Dennis,
> >
> > This makes me a bot confused in cmake_do_configure we have
> >
> >   -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
> >   ${EXTRA_OECMAKE} \
> >   -Wno-dev
> >
> > I would think that I am using this cmake_do_configure so then the
> > -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 should already be called correct?
> >
> > BR
> > Mans Zigher
>
> if you use "devtool build" from the extensible SDK to build a recipe
> that inherits cmake.bbclass, then the function cmake_do_configure() will
> be called implicitly.
>
> But if you manually compile a cmake project with the SDK, then that
> function won't be used. If your SDK contains the package
> nativesdk-cmake, then the SDK contains the following file:
>
>   $OECORE_NATIVE_SYSROOT/environment-setup.d/cmake.sh
>
> This file will be sourced along with the rest of the SDK and set an
> alias for cmake with an SDK-specific toolchain file.
>
> To verify if the option CMAKE_NO_SYSTEM_FROM_IMPORTED has been set by
> cmake, you can check if the file CMakeCache.txt (in the build directory)
> contains an entry for CMAKE_NO_SYSTEM_FROM_IMPORTED. An alternative way
> is to inspect the configuration via ccmake after calling cmake.
>
> Best regards,
> Dennis
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 1/1] nativesdk-packagegroup-sdk-host: add qemu to SDK

[Juro Bystricky]

Now that we can build qemu for mingw, include it in SDK.

Signed-off-by: Juro Bystricky 
---
 recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend 
b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
index 9629354..ad69b13 100644
--- a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
+++ b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
@@ -1,4 +1,5 @@
 RDEPENDS_${PN}_mingw32 = "\
 nativesdk-pkgconfig \
 nativesdk-libtool \
+nativesdk-qemu \
 "
-- 
2.7.4

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

[yocto] [meta-mingw][PATCH 0/1 Add QEMU to SDK

[Juro Bystricky]

Now that we can build QEMU for mingw, also include it in the SDK.
We have been able to build QEMU for Windows for a while now, but only
via a standalone recipe. QEMU has never been a part of SDK (as we were not
able to build it). The Autobuilder does test SDK build for mingw, but
does not test building of QEMU. Any QEMU build breakage (and there are 
occasional
ones) went unnoticed for periods of time and then we usually needed to bisect
the commits to find the culprit that broke the build.
So including QEMU in the SDK will have a nice sideffect: building QEMU will be 
tested
by the Autobuilder as well


Juro Bystricky (1):
  nativesdk-packagegroup-sdk-host: add qemu to SDK

 recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend | 1 +
 1 file changed, 1 insertion(+)

-- 
2.7.4

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

Re: [yocto] [meta-cgl][PATCH 0/5][RFC] CGL cleanup

[Adrian Dudau]

On mån, 2018-04-16 at 08:03 -0700, Armin Kuster wrote:
> I understand some of these changes a harsh. This set of changes allow
> this layer to pass the
> yocto-check-layer. This is one of many options to address passing.
>

Hi Armin,

Thanks for doing this. The series is good, and I merged it with some
minor changes, see below.

I also fixed the LAYERSERIES_COMPAT issue in meta-cgl-common so you
won't have to resend that series.

Regards,
--Adrian



> Armin Kuster (5):
>   meta-cgl-fsl-ppc: drop layer supporting old kernel

This patch didn't apply without your patches from the
LAYERSERIES_COMPAT series which wasn't correct. I was going to drop the
layer anyways, so I did it in a separate commit to simplify things.

>   Corosync: remove recipe its in meta-networking.
>   makedumpfile: remove as its in meta-oe
>   iscsi-initiator-utils: drop bbappends
>   meta-cge-common: Add README

Fixed typo in subject.

>
>  meta-cgl-common/README | 138
> ++
>  .../corosync/build-cleanup-configure-ac.patch  |  57 
>  .../corosync/corosync/corosync-docs.patch  |  37 -
>  .../corosync/corosync/corosync-notifyd.service |  13 --
>  .../recipes-cgl/corosync/corosync/corosync.init| 160 -
> 
>  .../recipes-cgl/corosync/corosync/corosync.service |  26 
>  .../corosync/corosync/fix-define-semun-union.patch |  20 ---
>  .../corosync/corosync/groff-desc-path.patch|  12 --
>  .../recipes-cgl/corosync/corosync/notifyd.init | 120 -
> ---
>  .../recipes-cgl/corosync/corosync/volatiles|   1 -
>  .../recipes-cgl/corosync/corosync_1.4.8.bb |  88 -
> ---
>  .../files/alias-powerpc-powerpc32.patch|  18 ---
>  .../recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb |  20 ---
>  .../iscsi-initiator-utils_%.bbappend   |   1 -
>  meta-cgl-fsl-ppc/conf/layer.conf   |  14 --
>  ...p-inherit-auth-capable-on-INIT-collisions.patch |  41 --
>  ...erpc-Fix-64-bit-builds-with-binutils-2.24.patch |  80 ---
>  .../linux/linux-qoriq-cgl-prt_3.12.bb  |  36 -
>  18 files changed, 138 insertions(+), 744 deletions(-)
>  create mode 100644 meta-cgl-common/README
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/build-cleanup-configure-ac.patch
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/corosync-docs.patch
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/corosync-notifyd.service
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/corosync.init
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/corosync.service
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/fix-define-semun-union.patch
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/groff-desc-path.patch
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/notifyd.init
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync/volatiles
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/corosync/corosync_1.4.8.bb
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
>  delete mode 100644 meta-cgl-common/recipes-
> cgl/makedumpfile/makedumpfile_1.5.8.bb
>  delete mode 100644 meta-cgl-common/recipes-extended/iscsi-initiator-
> utils/iscsi-initiator-utils_%.bbappend
>  delete mode 100644 meta-cgl-fsl-ppc/conf/layer.conf
>  delete mode 100644 meta-cgl-fsl-ppc/recipes-kernel/linux/files/Fix-
> CVE-2014-5077-sctp-inherit-auth-capable-on-INIT-collisions.patch
>  delete mode 100644 meta-cgl-fsl-ppc/recipes-
> kernel/linux/files/powerpc-Fix-64-bit-builds-with-binutils-2.24.patch
>  delete mode 100644 meta-cgl-fsl-ppc/recipes-kernel/linux/linux-
> qoriq-cgl-prt_3.12.bb
>
> --
> 2.7.4
>

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to patch a file in mysql recipe

[Greg Wilson-Lindberg]

I need to patch the my.cnf file that is part of the mysql/mariadb recipe. It 
lives in meta-openembedded/meta-oe/recipes-support/mysql/mariadb/my.cnf with 
the mariadb_5.5.52.bb file one level down.

I've set up a mariadb_5.5.52.bbappend file as:

FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/${PN}:"

SRC_URI += "file://my.cnf.patch"

# need to enable auto startup
SYSTEMD_AUTO_ENABLE_${PN}-server = "enable"


bitbake finds the my.cnf.patch file but reports that it can't find the my.cnf 
file to patch. I've set up patching of files that are downloaded as part of a 
source tree, but never tried to patch a file that is part of a recipe, and 
apparently I'm missing something. Is it possible to do this, and if so, can 
someone point out what I need to do to do it correctly?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Extensible SDK and DEFAULT_PREFERENCE

[Andrea Galbusera]

On Wed, Apr 18, 2018 at 2:41 PM, Martin Siegumfeldt  wrote:
> Hi,
>
> I am having a number of recipes residing in two versions, some (development 
> versions) being down-prioritized using:
>
> DEFAULT_PREFERENCE = "-1"
>
>
> The source code is hosted at a private git repository, and the git version is 
> selected using 'AUTOREV'. The extensible SDK renders successfully, however 
> the installation (by third party) fails:
>
> Traceback (most recent call last):
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 412, in DataSmart.expandWithRefs(s='dev+git${SRCPV}', varname='PV'):
>  try:
> >s = __expand_var_regexp__.sub(varparse.var_sub, s)
>  try:
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7, 
> 15), match='${SRCPV}'>):
>  else:
> >var = self.d.getVarFlag(key, "_content")
>  self.references.add(key)
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, 
> noweakdefault=False, parsing=False):
>  cachename = var + "[" + flag + "]"
> >value = self.expand(value, cachename)
>
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', 
> varname='SRCPV'):
>  def expand(self, s, varname = None):
> >return self.expandWithRefs(s, varname).value
>
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', 
> varname='SRCPV'):
>  except Exception as exc:
> >raise ExpansionError(varname, s, exc) from exc
>
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression 
> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
> failure: Fetch command export GIT_SSL_CAINFO="/home
> /martin/gomspace_sdk/buildtools/sysroots/x86_64-gomspacesdk-linux/etc/ssl/certs/ca-certificates.crt";
>  export 
> PATH="/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0
> /recipe-sysroot-native/usr/bin/python-native:/home/martin/gomspace_sdk/layers/poky/scripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/u
> sr/bin/aarch64-gomspace-linux:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomsp
> ace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/marti
> n/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-s
> ysroot-native/bin:/home/martin/gomspace_sdk/layers/poky/bitbake/bin:/home/martin/gomspace_sdk/tmp/hosttools";
>  export HOME="/home/martin"; git -c core.fsyncobjectfiles=0 ls-remote 
> ssh://g...@github.com/GomS
> pace/libisl  failed with exit code 128, output:
> Host key verification failed.
> fatal: Could not read from remote repository.
>
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> It is not the intention that third party will ever need access to the 
> development version, and I don't see why the version information is fetched 
> given the reduced priority. Have I encountered an 'undocumented bug' or is 
> there an alternate approach to achieve this?

eSDK and recipes doing AUTOREV are known to not play well (yet). There
is a bug open to address it at
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11350

>
> Thanks,
> Martin
> --
> ___
> 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 4/4] update_layer.py: move layer validation to update.py (Performance improve)

[Paul Eggleton]

On Wednesday, 18 April 2018 11:04:33 PM NZST Robert Yang wrote:
> The utils.setup_django() costs a lot of time, but both update.py and
> update_layer.py calls it, so move layer validation from update_layer.py to
> update.py to avoid calling update_layer.py when possible can save a lot of
> time.

Unfortunately I still can't merge this, as mentioned earlier it breaks 
handling older python 2-bound releases.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

[Dennis Menschel]

Hi Mans,

Am 18.04.2018 um 06:56 schrieb Måns Zigher:
> Hi Dennis,
> 
> This makes me a bot confused in cmake_do_configure we have
> 
>           -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
>           ${EXTRA_OECMAKE} \
>           -Wno-dev
> 
> I would think that I am using this cmake_do_configure so then the
> -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 should already be called correct?
> 
> BR
> Mans Zigher

if you use "devtool build" from the extensible SDK to build a recipe
that inherits cmake.bbclass, then the function cmake_do_configure() will
be called implicitly.

But if you manually compile a cmake project with the SDK, then that
function won't be used. If your SDK contains the package
nativesdk-cmake, then the SDK contains the following file:

  $OECORE_NATIVE_SYSROOT/environment-setup.d/cmake.sh

This file will be sourced along with the rest of the SDK and set an
alias for cmake with an SDK-specific toolchain file.

To verify if the option CMAKE_NO_SYSTEM_FROM_IMPORTED has been set by
cmake, you can check if the file CMakeCache.txt (in the build directory)
contains an entry for CMAKE_NO_SYSTEM_FROM_IMPORTED. An alternative way
is to inspect the configuration via ccmake after calling cmake.

Best regards,
Dennis



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

Re: [yocto] [PULL] provide debug sources in externalsrc -dbg packages

[Burton, Ross]

This is the wrong list, please submit the patch to
openembedded-c...@lists.openembedded.org.  Also the patches, not just
a link to the patches.

Ross

On 18 April 2018 at 05:14, Vignesh Rajendran (RBEI/ECF3)
 wrote:
> Hi Yocto,
>
>
>
> I have made some changes to fix missing debug sources in -dbg packages while
> using externalsrc.
>
> Please have look and let me know for any changes needed.
>
>
>
> Thanks. :-)
>
>
>
> the changes are available in the git repository at:
>
>
>
> https://git.yoctoproject.org/git/poky-contrib
> vrajendran/externalsrc-debugsrc
>
> http://git.yoctoproject.org/cgit.cgi//log/?h=vrajendran/externalsrc-debugsrc
>
>
>
> Vignesh Rajendran (1):
>
>   package.bbclass: provide debug sources in externalsrc -dbg packages
>
>
>
> meta/classes/externalsrc.bbclass |  3 +++
>
> meta/classes/package.bbclass | 14 +++---
>
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
>
>
> --
>
> 2.7.4
>
>
>
> Mit freundlichen Grüßen / Best regards
>
> Rajendran Vignesh
> RBEI/ECF33
>
> Tel. +91 422 67-65103
>
>
> --
> ___
> 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] [PULL] provide debug sources in externalsrc -dbg packages

[Vignesh Rajendran (RBEI/ECF3)]

Hi Yocto,

I have made some changes to fix missing debug sources in -dbg packages while 
using externalsrc.
Please have look and let me know for any changes needed.

Thanks. :-)

the changes are available in the git repository at:

https://git.yoctoproject.org/git/poky-contrib  vrajendran/externalsrc-debugsrc
http://git.yoctoproject.org/cgit.cgi//log/?h=vrajendran/externalsrc-debugsrc

Vignesh Rajendran (1):
  package.bbclass: provide debug sources in externalsrc -dbg packages

meta/classes/externalsrc.bbclass |  3 +++
meta/classes/package.bbclass | 14 +++---
2 files changed, 14 insertions(+), 3 deletions(-)

--
2.7.4

Mit freundlichen Grüßen / Best regards

Rajendran Vignesh
RBEI/ECF33

Tel. +91 422 67-65103

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

Re: [yocto] Extensible SDK and DEFAULT_PREFERENCE

[Khem Raj]

On Wed, Apr 18, 2018 at 5:41 AM, Martin Siegumfeldt  wrote:
> Hi,
>
> I am having a number of recipes residing in two versions, some (development 
> versions) being down-prioritized using:
>
> DEFAULT_PREFERENCE = "-1"
>
>
> The source code is hosted at a private git repository, and the git version is 
> selected using 'AUTOREV'. The extensible SDK renders successfully, however 
> the installation (by third party) fails:
>
> Traceback (most recent call last):
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 412, in DataSmart.expandWithRefs(s='dev+git${SRCPV}', varname='PV'):
>  try:
> >s = __expand_var_regexp__.sub(varparse.var_sub, s)
>  try:
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7, 
> 15), match='${SRCPV}'>):
>  else:
> >var = self.d.getVarFlag(key, "_content")
>  self.references.add(key)
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, 
> noweakdefault=False, parsing=False):
>  cachename = var + "[" + flag + "]"
> >value = self.expand(value, cachename)
>
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', 
> varname='SRCPV'):
>  def expand(self, s, varname = None):
> >return self.expandWithRefs(s, varname).value
>
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', 
> varname='SRCPV'):
>  except Exception as exc:
> >raise ExpansionError(varname, s, exc) from exc
>
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression 
> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
> failure: Fetch command export GIT_SSL_CAINFO="/home
> /martin/gomspace_sdk/buildtools/sysroots/x86_64-gomspacesdk-linux/etc/ssl/certs/ca-certificates.crt";
>  export 
> PATH="/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0
> /recipe-sysroot-native/usr/bin/python-native:/home/martin/gomspace_sdk/layers/poky/scripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/u
> sr/bin/aarch64-gomspace-linux:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomsp
> ace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/marti
> n/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-s
> ysroot-native/bin:/home/martin/gomspace_sdk/layers/poky/bitbake/bin:/home/martin/gomspace_sdk/tmp/hosttools";
>  export HOME="/home/martin"; git -c core.fsyncobjectfiles=0 ls-remote 
> ssh://g...@github.com/GomS
> pace/libisl  failed with exit code 128, output:
> Host key verification failed.
> fatal: Could not read from remote repository.
>
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> It is not the intention that third party will ever need access to the 
> development version, and I don't see why the version information is fetched 
> given the reduced priority. Have I encountered an 'undocumented bug' or is 
> there an alternate approach to achieve this?

AUTOREV is floating dependency, fetcher has to ensure to get a value
for it to populate version strings
before comparing which one to use. you might be able to use BBMASK
effectively to eliminate these
recips from parsers visibility completely.

>
> Thanks,
> Martin
> --
> ___
> 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] Need Help for meta-qt5

[Vincent Daanen]

Hi,

I have to add Qt5 QtCore libs to my image. I know I must use meta-qt5 but as 
I'm not familiar with qt configuration, I simply do not know how to start !
So can someone help me to configure meta-qt5 to simply build and add QtCore to 
my image ?
Thank you

Vincent


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

Re: [yocto] Connecting to mysql/mariadb

[Martin Hundebøll]

Hi Greg,

On 2018-04-17 18:50, Greg Wilson-Lindberg wrote:
I've got a Yocto system that I'm working on that has mysql/mariadb 
configured but I can't connect to it with MySQL Workbench from another 
machine. mariadb is running, the network connection is live, but when I 
try to connect using MySQL Workbench I get an immediate "connection 
refused" response. I've tried user root, & mysql, same response. I'm 
using the default configuration from Yocto, so maybe I'm missing 
something that I should be configuring.



If anybody here has any experience with this I would appreciate any 
enlightenment you can give me.


By default, mysql only listens on local interfaces. To make it listen on 
"external" interfaces also, change the "bind-address" setting in 
/etc/my.cnf on the target, and restart mysql.


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

Re: [yocto] Connecting to mysql/mariadb

[Victor Palacio]

Hi Greg,


There are no leads to follow in logs? How about using netstat to check 
if port is really open?


Can you connect locally from a mysql client running in the device 
instead of using it externally?



BTW, verify that the skip-networking paramater is commented in your 
my.cnf file. Maybe networking is disabled by default.



Regards,



El 17/04/18 a las 18:50, Greg Wilson-Lindberg escribió:


I've got a Yocto system that I'm working on that has mysql/mariadb 
configured but I can't connect to it with MySQL Workbench from another 
machine. mariadb is running, the network connection is live, but when 
I try to connect using MySQL Workbench I get an immediate "connection 
refused" response. I've tried user root, & mysql, same response. I'm 
using the default configuration from Yocto, so maybe I'm missing 
something that I should be configuring.



If anybody here has any experience with this I would appreciate any 
enlightenment you can give me.



Thanks in advance,

Greg Wilson-Lindberg






--

Victor M. Palacio Tárrega

vpala...@intemotechnologies.com 

**

*Intemo Technologies- Idetech Europe, S.L.*

Mov.: (+34)  670 03 66 08

Tel: (+34) 93 336 16 51

C/ Montserrat Roig, nº 23, Pol. Ind. Pedrosa

08908 Hospitalet de Llobregat

BARCELONA (SPAIN)

| SmartCards |RFID |NFC |Biometría |

Este correo electrónico puede contener información reservada 
y/o confidencial, destinada exclusivamente para el uso del destinatario. 
Si Vd no es el destinatario o la persona encargada de distribuirlo, no 
está autorizado a copiar o entregar esta comunicación a ninguna otra 
persona. Si ha recibido este correo electrónico por error, le rogamos 
nos lo notifique inmediatamente por  teléfono o por el mismo medio. Gracias.


Privilege/Confidential Information may be contained in this e-mail and 
is intended only for use of the addressee. If you are not  the 
addressee, or the person responsible for delivering it to the person 
addressed, you may not copy or deliver this to anyone else. If you 
receive this e-mail by mistake, please notify us immediately by 
telephone or e-mail. Thank you.


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

[yocto] Extensible SDK and DEFAULT_PREFERENCE

[Martin Siegumfeldt]

Hi,

I am having a number of recipes residing in two versions, some (development 
versions) being down-prioritized using:

DEFAULT_PREFERENCE = "-1"


The source code is hosted at a private git repository, and the git version is 
selected using 'AUTOREV'. The extensible SDK renders successfully, however the 
installation (by third party) fails:

Traceback (most recent call last):
  File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
line 412, in DataSmart.expandWithRefs(s='dev+git${SRCPV}', varname='PV'):
                 try:
    >                s = __expand_var_regexp__.sub(varparse.var_sub, s)
                     try:
  File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7, 15), 
match='${SRCPV}'>):
                 else:
    >                var = self.d.getVarFlag(key, "_content")
                 self.references.add(key)
  File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, 
noweakdefault=False, parsing=False):
                     cachename = var + "[" + flag + "]"
    >            value = self.expand(value, cachename)
     
  File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', varname='SRCPV'):
         def expand(self, s, varname = None):
    >        return self.expandWithRefs(s, varname).value
     
  File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', 
varname='SRCPV'):
                 except Exception as exc:
    >                raise ExpansionError(varname, s, exc) from exc
     
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was 
${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
failure: Fetch command export GIT_SSL_CAINFO="/home
/martin/gomspace_sdk/buildtools/sysroots/x86_64-gomspacesdk-linux/etc/ssl/certs/ca-certificates.crt";
 export 
PATH="/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0
/recipe-sysroot-native/usr/bin/python-native:/home/martin/gomspace_sdk/layers/poky/scripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/u
sr/bin/aarch64-gomspace-linux:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomsp
ace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/marti
n/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-s
ysroot-native/bin:/home/martin/gomspace_sdk/layers/poky/bitbake/bin:/home/martin/gomspace_sdk/tmp/hosttools";
 export HOME="/home/martin"; git -c core.fsyncobjectfiles=0 ls-remote 
ssh://g...@github.com/GomS
pace/libisl  failed with exit code 128, output:
Host key verification failed.
fatal: Could not read from remote repository.


Please make sure you have the correct access rights
and the repository exists.

It is not the intention that third party will ever need access to the 
development version, and I don't see why the version information is fetched 
given the reduced priority. Have I encountered an 'undocumented bug' or is 
there an alternate approach to achieve this?

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

Re: [yocto] [PATCH 0/4][layerindex-web] bug fix and performance improve

[Burton, Ross]

On 18 April 2018 at 12:04, Robert Yang  wrote:
>   fixup! update: don't stop on unsatisfied layer dependencies

Pretty sure this isn't what you intended.

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

[yocto] [PATCH 4/4] update_layer.py: move layer validation to update.py (Performance improve)

[Robert Yang]

The utils.setup_django() costs a lot of time, but both update.py and
update_layer.py calls it, so move layer validation from update_layer.py to
update.py to avoid calling update_layer.py when possible can save a lot of
time.

Now we don't have to call update_layer.py in the following cases:
* The branch doesn't exist
* The layer is already update to date on specified branch (when no
  reload)
* The layer dir or conf/layer.layer doesn't exist

We can save up to 98% time in my testing:

$ update.py -b master --nofetch [--fullreload]

   BeforeNow   Reduced
No update: 276s  3.6s  98%
Partial update:312s  87s   72%
Full repload:  1016s 980s  3%

Note:
* All of the testing are based on --nofetch

* "No update" means all layers on the branch is up-to-date, for
  example, when we run it twice, there is no update in the second run, so we
  only need about 3s now, which is the most common case when we use cron to run
  it per half an hour.

* "Partly update" means part of the layers have been updated.

* "Fullreload" means all of the layers have been updated.

Signed-off-by: Robert Yang 
---
 layerindex/update.py   | 79 +-
 layerindex/update_layer.py | 39 +++
 2 files changed, 82 insertions(+), 36 deletions(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index 44a7b90..2bb2df7 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -140,6 +140,15 @@ def fetch_repo(vcs_url, repodir, urldir, fetchdir, 
layer_name):
 logger.error("Fetch of layer %s failed: %s" % (layer_name, e.output))
 return (vcs_url, e.output)
 
+def print_subdir_error(newbranch, layername, vcs_subdir, branchdesc):
+# This will error out if the directory is completely invalid or had never 
existed at this point
+# If it previously existed but has since been deleted, you will get the 
revision where it was
+# deleted - so we need to handle that case separately later
+if newbranch:
+logger.info("Skipping update of layer %s for branch %s - subdirectory 
%s does not exist on this branch" % (layername, branchdesc, vcs_subdir))
+elif vcs_subdir:
+logger.error("Subdirectory for layer %s does not exist on branch %s - 
if this is legitimate, the layer branch record should be deleted" % (layername, 
branchdesc))
+
 def main():
 if LooseVersion(git.__version__) < '0.3.1':
 logger.error("Version of GitPython is too old, please install 
GitPython (python-git) 0.3.1 or later in order to use this script")
@@ -195,7 +204,7 @@ def main():
 
 utils.setup_django()
 import settings
-from layerindex.models import Branch, LayerItem, Update, LayerUpdate
+from layerindex.models import Branch, LayerItem, Update, LayerUpdate, 
LayerBranch
 
 logger.setLevel(options.loglevel)
 
@@ -337,6 +346,74 @@ def main():
 collections.add((layerbranch.collection, 
layerbranch.version))
 
 for layer in layerquery:
+layerbranch = layer.get_layerbranch(branch)
+branchname = branch
+branchdesc = branch
+newbranch = False
+branchobj = utils.get_branch(branch)
+if layerbranch:
+if layerbranch.actual_branch:
+branchname = layerbranch.actual_branch
+branchdesc = "%s (%s)" % (branch, branchname)
+else:
+# LayerBranch doesn't exist for this branch, create it
+newbranch = True
+layerbranch = LayerBranch()
+layerbranch.layer = layer
+layerbranch.branch = branchobj
+layerbranch_source = layer.get_layerbranch(branchobj)
+if not layerbranch_source:
+layerbranch_source = layer.get_layerbranch(None)
+if layerbranch_source:
+layerbranch.vcs_subdir = 
layerbranch_source.vcs_subdir
+
+# Collect repo info
+urldir = layer.get_fetch_dir()
+repodir = os.path.join(fetchdir, urldir)
+repo = git.Repo(repodir)
+assert repo.bare == False
+try:
+if options.nocheckout:
+topcommit = repo.commit('HEAD')
+else:
+topcommit = repo.commit('origin/%s' % branchname)
+except:
+if newbranch:
+logger.info("Skipping update of layer %s - branch 
%s doesn't exist" % (layer.name, branchdesc))
+else:
+logger.info("layer %s - branch %s no longer 
exists, removin

[yocto] [PATCH 3/4] update.py: print failed layers summary in the end

[Robert Yang]

This makes it easy to see which layers are failed. For example:

ERROR: Failed layers on branch master: openembedded-core meta-python

Signed-off-by: Robert Yang 
---
 layerindex/update.py | 9 +
 1 file changed, 9 insertions(+)

diff --git a/layerindex/update.py b/layerindex/update.py
index e4ca7b6..44a7b90 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -319,6 +319,7 @@ def main():
 # unreliable due to leaking memory (we're using bitbake internals 
in a manner in which
 # they never get used during normal operation).
 last_rev = {}
+failed_layers = {}
 for branch in branches:
 # If layer_A depends(or recommends) on layer_B, add layer_B 
before layer_A
 deps_dict_all = {}
@@ -384,9 +385,12 @@ def main():
 # If nothing changed after a run then some dependencies 
couldn't be resolved
 if operator.eq(deps_dict_all_copy, deps_dict_all):
 logger.warning("Cannot find required collections on 
branch %s:" % branch)
+layer_names = []
 for layer, value in deps_dict_all.items():
 logger.error('%s: %s' % (layer.name, 
value['requires']))
+layer_names.append(layer.name)
 logger.warning("Known collections on branch %s: %s" % 
(branch, collections))
+failed_layers[branch] = layer_names
 break
 
 for layer in layerquery_sorted:
@@ -427,6 +431,11 @@ def main():
 # Interrupted by user, break out of loop
 logger.info('Update interrupted, exiting')
 sys.exit(254)
+if failed_layers:
+print()
+for branch, err_msg_list in failed_layers.items():
+logger.error("Failed layers on branch %s: %s" % (branch, " 
".join(err_msg_list)))
+print()
 finally:
 utils.unlock_file(lockfile)
 
-- 
2.7.4

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

[yocto] [PATCH 2/4] update.py: add an option --timeout for lockfile

[Robert Yang]

We have an update.py running perodically in background, but we also need run it
manually, for example, run it to update actual_branch, the manually run usually
failed because can't get lockfile, we have to run it again and again. A timeout
option helps a lot in such a case. Now the following command can make sure we
can run the command successfully:
$ update.py -b master -a actual_branch -t 2000

Signed-off-by: Robert Yang 
---
 layerindex/update.py |  5 -
 layerindex/utils.py  | 14 +++---
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index 07240ab..e4ca7b6 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -156,6 +156,9 @@ def main():
 parser.add_option("-l", "--layer",
 help = "Specify layers to update (use commas to separate 
multiple). Default is all published layers.",
 action="store", dest="layers")
+parser.add_option("-t", "--timeout",
+help = "Specify timeout in seconds to get layerindex.lock. Default 
is 30 seconds.",
+type="int", action="store", dest="timeout", default=30)
 parser.add_option("-r", "--reload",
 help = "Reload recipe data instead of updating since last update",
 action="store_true", dest="reload")
@@ -265,7 +268,7 @@ def main():
 update.save()
 try:
 lockfn = os.path.join(fetchdir, "layerindex.lock")
-lockfile = utils.lock_file(lockfn)
+lockfile = utils.lock_file(lockfn, options.timeout, logger)
 if not lockfile:
 logger.error("Layer index lock timeout expired")
 sys.exit(1)
diff --git a/layerindex/utils.py b/layerindex/utils.py
index 08a4001..ebcfcaf 100644
--- a/layerindex/utils.py
+++ b/layerindex/utils.py
@@ -309,8 +309,10 @@ class ListHandler(logging.Handler):
 return log
 
 
-def lock_file(fn):
-starttime = time.time()
+def lock_file(fn, timeout=30, logger=None):
+start = time.time()
+last = start
+counter = 1
 while True:
 lock = open(fn, 'w')
 try:
@@ -318,8 +320,14 @@ def lock_file(fn):
 return lock
 except IOError:
 lock.close()
-if time.time() - starttime > 30:
+current = time.time()
+if current - start > timeout:
 return None
+# Print a message in every 5 seconds
+if logger and (current - last > 5):
+last = current
+logger.info('Trying to get lock on %s (tried %s seconds) ...' 
% (fn, (5 * counter)))
+counter += 1
 
 def unlock_file(lock):
 fcntl.flock(lock, fcntl.LOCK_UN)
-- 
2.7.4

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

[yocto] [PATCH 1/4] fixup! update: don't stop on unsatisfied layer dependencies

[Robert Yang]

The previous commit broke the layer order, e.g.:
A -> B -> C -> D

The algorithm is checking the dependencies one by one, and until we find D, add
D to layerquery_sorted, and add it "collections", the one in "collections"
means it's dependencies are OK, then C, B and A will check against collections,
so that update_layer.py will update them one by one. The previous commit added
A/B/C/D to collections directly, so that when check against it, all the
dependencies are met, thus broke the layer sorting, and then there would be
failures if we pass layer A to update_layer.py before B, C and D (suppose they
are newly to database). This commit fix the problem.

BTW., why I use collections to record the one whose dependencies are matched,
but not directly use layerquery_sorted, it is because collections contains both
the ones to be added/updated and the ones in database, but layerquery_sorted
only contains the ones to be updated/added.

Signed-off-by: Robert Yang 
---
 layerindex/update.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index f60b943..07240ab 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -348,12 +348,11 @@ def main():
 deps = re.search("^LAYERDEPENDS = \"(.*)\"", output, 
re.M).group(1) or ''
 recs = re.search("^LAYERRECOMMENDS = \"(.*)\"", output, 
re.M).group(1) or ''
 
-collections.add((col, ver))
-
 deps_dict = utils.explode_dep_versions2(bitbakepath, deps 
+ ' ' + recs)
 if len(deps_dict) == 0:
 # No depends, add it firstly
 layerquery_sorted.append(layer)
+collections.add((col, ver))
 continue
 deps_dict_all[layer] = {'requires': deps_dict, 
'collection': col, 'version': ver}
 
@@ -374,6 +373,7 @@ def main():
 # All the depends are in collections:
 del(deps_dict_all[layer])
 layerquery_sorted.append(layer)
+collections.add((value['collection'], 
value['version']))
 
 if not len(deps_dict_all):
 break
-- 
2.7.4

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

[yocto] [PATCH 0/4][layerindex-web] bug fix and performance improve

[Robert Yang]

Hi Paul,

The patch 4 can improve a lot on update.py (up to 98%), here is the testing
data, please feel free to give your comments.

$ time update.py -b master --nofetch [--fullreload]

   BeforeNow   Reduced
No update: 276s  3.6s  98%
Partial update:312s  87s   72%
Full repload:  1016s 980s  3%

Note:
* All of the testing are based on --nofetch

* "No update" means all layers on the branch is up-to-date, for
  example, when we run it twice, there is no update in the second run, so we
  only need about 3s now, which is the most common case when we use cron to run
  it per half an hour.

* "Partly update" means part of the layers have been updated.

* "Fullreload" means all of the layers have been updated.

// Robert

The following changes since commit 611c96883c35240d3c291951146154d828745774:

  requirements.txt: use the most recent Django 1.8 version (2018-03-26 08:29:27 
+1300)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib rbt/layerindex
  http://git.pokylinux.org/cgit.cgi//log/?h=rbt/layerindex

Robert Yang (4):
  fixup! update: don't stop on unsatisfied layer dependencies
  update.py: add an option --timeout for lockfile
  update.py: print failed layers summary in the end
  update_layer.py: move layer validation to update.py (Performance
improve)

 layerindex/update.py   | 97 --
 layerindex/update_layer.py | 39 ++-
 layerindex/utils.py| 14 +--
 3 files changed, 108 insertions(+), 42 deletions(-)

-- 
2.7.4

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

[yocto] [meta-security][PATCH] xmlsec1: remove host paths from target files

[wenzong.fan]

From: Wenzong Fan 

Signed-off-by: Wenzong Fan 
---
 recipes-security/xmlsec1/xmlsec1_1.2.25.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/recipes-security/xmlsec1/xmlsec1_1.2.25.bb 
b/recipes-security/xmlsec1/xmlsec1_1.2.25.bb
index dbb6f7d..341ca08 100644
--- a/recipes-security/xmlsec1/xmlsec1_1.2.25.bb
+++ b/recipes-security/xmlsec1/xmlsec1_1.2.25.bb
@@ -46,7 +46,10 @@ do_compile_ptest () {
 }
 
 do_install_append() {
-sed -i -e "s@${STAGING_DIR}@@g" ${D}${bindir}/xmlsec1-config
+for i in ${bindir}/xmlsec1-config ${libdir}/xmlsec1Conf.sh \
+${libdir}/pkgconfig/xmlsec1-openssl.pc; do
+sed -i -e "s@${RECIPE_SYSROOT}@@g" ${D}$i
+done
 }
 
 do_install_ptest () {
-- 
2.8.1

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