Re: [oe] [RESEND meta-python PATCH 2/2] python3-requests: Remove RDEPENDS on python3-misc

[Otavio Salvador]

On Wed, Feb 21, 2018 at 6:48 PM, Alejandro Enedino Hernandez Samaniego
 wrote:
> Just to clarify that the misc package wasnt removed, it still exists, but
> with the rework
>
> selectors was put on core, so your patch is fine, but what was removed was
> the
>
> dependency on misc, not the package itself, just a technicality.

Sent a v2. Thanks for the review :-)

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-python PATCH v2 2/2] python3-requests: Remove RDEPENDS on python3-misc

[Otavio Salvador]

The selectors module is now part of python3-core. Remove this
dependency.
Tested using updatehub's uhu utility.

Signed-off-by: Otavio Salvador 
---

Changes in v2:
- Fix commit log

 meta-python/recipes-devtools/python/python3-requests_2.18.4.bb | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb 
b/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb
index d91d993bf..0a2410f85 100644
--- a/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb
+++ b/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb
@@ -1,5 +1,2 @@
 inherit setuptools3
 require python-requests.inc
-
-# Add the runtime depends for selectors.py
-RDEPENDS_${PN} += "${PYTHON_PN}-misc"
-- 
2.16.2

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-python PATCH v2 1/2] python3-jsonschema: Remove RDEPENDS on python3-misc

[Otavio Salvador]

The misc dependency is not need anymore since python3 package rework.

Tested using updatehub's uhu utility.

Signed-off-by: Otavio Salvador 
---

Changes in v2:
- Rework commit log.

 meta-python/recipes-devtools/python/python3-jsonschema_2.6.0.bb | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta-python/recipes-devtools/python/python3-jsonschema_2.6.0.bb 
b/meta-python/recipes-devtools/python/python3-jsonschema_2.6.0.bb
index 5aaee682b..926990747 100644
--- a/meta-python/recipes-devtools/python/python3-jsonschema_2.6.0.bb
+++ b/meta-python/recipes-devtools/python/python3-jsonschema_2.6.0.bb
@@ -1,6 +1,2 @@
 inherit pypi setuptools3
 require python-jsonschema.inc
-
-RDEPENDS_${PN} += " \
-${PYTHON_PN}-misc \
-"
-- 
2.16.2

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Jonas Bonn]

On 21 February 2018 at 15:09, Martin Hundebøll  wrote:

> Now that the discussion branched out a bit...
>
> We would like better support for this too. Our setup uses a "manifest"
> repository with git submodules to setup the layers:
>
> > yocto/
> >   meta-poky/
> >   meta-qt5/
> >   meta-foo/
> >   meta-bar/
> >   conf/
> >bblayers.conf
> >local.conf
> >   .gitmodules
>
> With this setup, customers simply need to clone our yocto repo
> recursively, run `yocto/meta-poky/oe-init-build-env yocto` and then
> `bitbake image-recipe`.
>
> But this is rather inflexible, as it requires the "yocto" folder to be the
> build folder to activate the config files...
>
> We looked into putting the configs in "meta-foo/conf/*.conf.sample" and
> using TEMPLATECONF, but the "oe-init-build-env" script is rather picky
> about poky being the "top" directory.
>
> I guess the oe-init-build-env script can be changed to look for
> .templateconf in any parent folder?


Putting together a deliverable setup that's easy for the customer to get
started with is a bit tricky.  Here's the approach that's worked well for
me:

/myproject
/env<-- script
/build
/meta-myproject
/bitbake
/oe-core
/meta-layer1
/meta-layer2

env, build, meta-myproject are part of the myproject repo, everything else
is a submodule.

"env" is a script containing just the following:
. ./oe-core/oe-init-build-env build/ bitbake/

meta-myproject is the "local layer" that contains project specific recipes
and appends.

The build directory contains:
build/conf/bblayers.conf.sample
build/conf/conf-notes.txt
build/conf/local.conf.sample
build/conf/templateconf.cfg

The interesting parts here are:
bblayers.conf.sample contains something like this:
BBLAYERS ?= " \
  ##OEROOT##/meta \
  ##OEROOT##/../meta-layer1 \
  ##OEROOT##/../meta-layer2 \
  ##OEROOT##/../meta-myproject \
  "

and templateconf.cfg contains this magic:
../build/conf

With this setup, the customer does:
git clone /myproject.git
git submodule --update init
./env
bitbake customer-image

The 'env' command nicely prints the contents of conf-notes which reminds
the customer of the names of the images (customer-image,
customer-dev-image, customer-special-image, etc) that are avaiable to be
built so that they don't need to search the repo for the image recipes
because they can't remember what they were called.

The only additional tweak that I recommand be made manually beyond the
above is to point build/sstate-cache to somewhere outside of the cloned
repo.  That way, the entire repo can be deleted, re-cloned, and quickly
rebuilt when people get themselves lost in the labyrinth...

Advantages of the above:
i)  oe-core is just another layer and therefore just another submodule...
no changes are made to it locally
ii)  git log on the myproject repo ties submodule updates and modifications
to the "local layer" together so it's clear why recipes were changed
iii)  since meta-mylayer is not an external layer/repo, I'm working in only
one git repo when doing updates (assuming the submodules aren't changing)

Anyway, just wanted to share that, in case it's useful for someone.

/Jonas
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-perl][PATCH 2/2] libmodule-runtime-perl: upgrade to 0.016, use upstream

[Tim Orling]

Upstream has fixed build system to use EUMM, so we no
longer need the fix on github.com/moto-timo.

Add UPSTREAM_CHECK_REGEX to ensure we catch future updates.

Extended the license checksum to include the Copyright.
The length of the README file has changed, so the checksum
has changed. Verified that the license remains the same.

Signed-off-by: Tim Orling 
---
 ...runtime-perl_0.015.bb => libmodule-runtime-perl_0.016.bb} | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)
 rename meta-perl/recipes-perl/libmodule/{libmodule-runtime-perl_0.015.bb => 
libmodule-runtime-perl_0.016.bb} (75%)

diff --git a/meta-perl/recipes-perl/libmodule/libmodule-runtime-perl_0.015.bb 
b/meta-perl/recipes-perl/libmodule/libmodule-runtime-perl_0.016.bb
similarity index 75%
rename from meta-perl/recipes-perl/libmodule/libmodule-runtime-perl_0.015.bb
rename to meta-perl/recipes-perl/libmodule/libmodule-runtime-perl_0.016.bb
index b92842c46..89f0f709a 100644
--- a/meta-perl/recipes-perl/libmodule/libmodule-runtime-perl_0.015.bb
+++ b/meta-perl/recipes-perl/libmodule/libmodule-runtime-perl_0.016.bb
@@ -17,12 +17,14 @@ SECTION = "libs"
 HOMEPAGE = "http://search.cpan.org/~zefram/Module-Runtime/;
 
 LICENSE = "Artistic-1.0 | GPL-1.0+"
-LIC_FILES_CHKSUM = 
"file://README;beginline=45;endline=46;md5=62e24a93342fede7221d66335c716f34"
+LIC_FILES_CHKSUM = 
"file://README;beginline=36;endline=44;md5=9416434672a57853d6181f3da9094963"
 
-SRCNAME = "module-runtime"
-SRC_URI = "https://github.com/moto-timo/${SRCNAME}/archive/${PV}.tar.gz;
-SRC_URI[md5sum] = "ad6ca179c978aa02ac8aa29244ef9beb"
-SRC_URI[sha256sum] = 
"59effa82b3f6986d28de6154a8f2428157691004d951f936a81e851f4dbcb045"
+SRCNAME = "Module-Runtime"
+SRC_URI = "${CPAN_MIRROR}/authors/id/Z/ZE/ZEFRAM/${SRCNAME}-${PV}.tar.gz"
+SRC_URI[md5sum] = "d3d47222fa2e3dfcb4526f6cc8437b20"
+SRC_URI[sha256sum] = 
"68302ec646833547d410be28e09676db75006f4aa58a11f3bdb44ffe99f0f024"
+
+UPSTREAM_CHECK_REGEX = "Module\-Runtime\-(?P(\d+\.\d+)).tar"
 
 S = "${WORKDIR}/${SRCNAME}-${PV}"
 
-- 
2.13.6

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-perl][PATCH 1/2] libmodule-pluggable-perl: use upstream instead of github.com/moto-timo

[Tim Orling]

Upstream has updated the build system to use EUMM, so the fix on
github.com/moto-timo is no longer needed.

Because the versions where out of sync, reflect the bump in PR.

Add UPSTREAM_CHECK_REGEX to properly catch upstream updates.

Signed-off-by: Tim Orling 
---
 .../recipes-perl/libmodule/libmodule-pluggable-perl_5.2.bb| 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/meta-perl/recipes-perl/libmodule/libmodule-pluggable-perl_5.2.bb 
b/meta-perl/recipes-perl/libmodule/libmodule-pluggable-perl_5.2.bb
index c73a15a4f..aed65d3a8 100644
--- a/meta-perl/recipes-perl/libmodule/libmodule-pluggable-perl_5.2.bb
+++ b/meta-perl/recipes-perl/libmodule/libmodule-pluggable-perl_5.2.bb
@@ -17,9 +17,14 @@ LICENSE = "Artistic-1.0 | GPL-1.0+"
 LIC_FILES_CHKSUM = 
"file://README;beginline=322;endline=325;md5=086450ce010f6fda25db0b38fcc41086"
 
 SRCNAME = "Module-Pluggable"
-SRC_URI = "https://github.com/moto-timo/${SRCNAME}/archive/${PV}.tar.gz;
-SRC_URI[md5sum] = "e32475d6ff5843f738cedacd3b7a2cdb"
-SRC_URI[sha256sum] = 
"58c62292eea6d06959eba1b97598650813211265403242d57efb2f605c96059f"
+SRC_URI = "${CPAN_MIRROR}/authors/id/S/SI/SIMONW/${SRCNAME}-${PV}.tar.gz"
+SRC_URI[md5sum] = "87ce2971662efd0b69a81bb4dc9ea76c"
+SRC_URI[sha256sum] = 
"b3f2ad45e4fd10b3fb90d912d78d8b795ab295480db56dc64e86b9fa75c5a6df"
+
+PR = "r1"
+
+UPSTREAM_CHECK_REGEX = "Module\-Pluggable\-(?P(\d+\.\d+))"
+UPSTREAM_CHECK_URI = "https://metacpan.org/release/${SRCNAME};
 
 S = "${WORKDIR}/${SRCNAME}-${PV}"
 
-- 
2.13.6

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-qt5][PATCH 1/2] qtbase: Replace -isystem with -I

[Khem Raj]

this patch is resent because now its rebased on top of master-next

On Wed, Feb 21, 2018 at 8:29 PM, Khem Raj  wrote:
> Fixes no-x11 builds (eglfs)
>
> Signed-off-by: Khem Raj 
> ---
>  recipes-qt/qt5/qtbase-native_git.bb|  1 +
>  ...mon-gcc-base.conf-Use-I-instead-of-isyste.patch | 36 
> ++
>  recipes-qt/qt5/qtbase_git.bb   |  1 +
>  3 files changed, 38 insertions(+)
>  create mode 100644 
> recipes-qt/qt5/qtbase/0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch
>
> diff --git a/recipes-qt/qt5/qtbase-native_git.bb 
> b/recipes-qt/qt5/qtbase-native_git.bb
> index 20e24eb..5fa24d3 100644
> --- a/recipes-qt/qt5/qtbase-native_git.bb
> +++ b/recipes-qt/qt5/qtbase-native_git.bb
> @@ -34,6 +34,7 @@ SRC_URI += "\
>  file://0009-Add-OE-specific-specs-for-clang-compiler.patch \
>  file://0010-linux-clang-Invert-conditional-for-defining-QT_SOCKL.patch \
>  file://0011-tst_qlocale-Enable-QT_USE_FENV-only-on-glibc.patch \
> +file://0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch \
>  "
>
>  # common for qtbase-native and nativesdk-qtbase
> diff --git 
> a/recipes-qt/qt5/qtbase/0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch
>  
> b/recipes-qt/qt5/qtbase/0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch
> new file mode 100644
> index 000..44e9009
> --- /dev/null
> +++ 
> b/recipes-qt/qt5/qtbase/0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch
> @@ -0,0 +1,36 @@
> +From 61c858474804fd772d612e6c5b4bb6df261d521a Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Wed, 14 Feb 2018 17:08:43 -0800
> +Subject: [PATCH] mkspecs/common/gcc-base.conf: Use -I instead of -isystem
> +
> +-isystem fails to build when code uses include_next on certain files e.g.
> +
> +qtbase/5.10.0+gitAUTOINC+50117d738a-r0/recipe-sysroot/usr/include/c++/7.3.0/cstdlib:75:15:
>  fatal error: stdlib.h: No such file or directory
> + #include_next 
> +   ^~
> +compilation terminated.
> +make[2]: *** [Makefile:11592: .obj/qgenericpluginfactory.o] Error 1
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Khem Raj 
> +---
> + mkspecs/common/gcc-base.conf | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/mkspecs/common/gcc-base.conf b/mkspecs/common/gcc-base.conf
> +index 234f71d495..ee3da023e6 100644
> +--- a/mkspecs/common/gcc-base.conf
>  b/mkspecs/common/gcc-base.conf
> +@@ -46,7 +46,7 @@ QMAKE_CFLAGS_DEBUG += -g
> + QMAKE_CFLAGS_SHLIB += $$QMAKE_CFLAGS_PIC
> + QMAKE_CFLAGS_STATIC_LIB+= $$QMAKE_CFLAGS_PIC
> + QMAKE_CFLAGS_APP   += $$QMAKE_CFLAGS_PIC
> +-QMAKE_CFLAGS_ISYSTEM= -isystem
> ++QMAKE_CFLAGS_ISYSTEM= -I
> + QMAKE_CFLAGS_YACC  += -Wno-unused -Wno-parentheses
> + QMAKE_CFLAGS_HIDESYMS  += -fvisibility=hidden
> + QMAKE_CFLAGS_EXCEPTIONS_OFF += -fno-exceptions
> +--
> +2.16.1
> +
> diff --git a/recipes-qt/qt5/qtbase_git.bb b/recipes-qt/qt5/qtbase_git.bb
> index 522e261..e495b8c 100644
> --- a/recipes-qt/qt5/qtbase_git.bb
> +++ b/recipes-qt/qt5/qtbase_git.bb
> @@ -30,6 +30,7 @@ SRC_URI += "\
>  file://0009-Add-OE-specific-specs-for-clang-compiler.patch \
>  file://0010-linux-clang-Invert-conditional-for-defining-QT_SOCKL.patch \
>  file://0011-tst_qlocale-Enable-QT_USE_FENV-only-on-glibc.patch \
> +file://0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch \
>  "
>
>  # LGPL-3.0 is used only in src/plugins/platforms/android/extract.cpp
> --
> 2.16.2
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-qt5][PATCH 1/2] qtbase: Replace -isystem with -I

[Khem Raj]

Fixes no-x11 builds (eglfs)

Signed-off-by: Khem Raj 
---
 recipes-qt/qt5/qtbase-native_git.bb|  1 +
 ...mon-gcc-base.conf-Use-I-instead-of-isyste.patch | 36 ++
 recipes-qt/qt5/qtbase_git.bb   |  1 +
 3 files changed, 38 insertions(+)
 create mode 100644 
recipes-qt/qt5/qtbase/0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch

diff --git a/recipes-qt/qt5/qtbase-native_git.bb 
b/recipes-qt/qt5/qtbase-native_git.bb
index 20e24eb..5fa24d3 100644
--- a/recipes-qt/qt5/qtbase-native_git.bb
+++ b/recipes-qt/qt5/qtbase-native_git.bb
@@ -34,6 +34,7 @@ SRC_URI += "\
 file://0009-Add-OE-specific-specs-for-clang-compiler.patch \
 file://0010-linux-clang-Invert-conditional-for-defining-QT_SOCKL.patch \
 file://0011-tst_qlocale-Enable-QT_USE_FENV-only-on-glibc.patch \
+file://0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch \
 "
 
 # common for qtbase-native and nativesdk-qtbase
diff --git 
a/recipes-qt/qt5/qtbase/0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch
 
b/recipes-qt/qt5/qtbase/0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch
new file mode 100644
index 000..44e9009
--- /dev/null
+++ 
b/recipes-qt/qt5/qtbase/0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch
@@ -0,0 +1,36 @@
+From 61c858474804fd772d612e6c5b4bb6df261d521a Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Wed, 14 Feb 2018 17:08:43 -0800
+Subject: [PATCH] mkspecs/common/gcc-base.conf: Use -I instead of -isystem
+
+-isystem fails to build when code uses include_next on certain files e.g.
+
+qtbase/5.10.0+gitAUTOINC+50117d738a-r0/recipe-sysroot/usr/include/c++/7.3.0/cstdlib:75:15:
 fatal error: stdlib.h: No such file or directory
+ #include_next 
+   ^~
+compilation terminated.
+make[2]: *** [Makefile:11592: .obj/qgenericpluginfactory.o] Error 1
+
+Upstream-Status: Pending
+
+Signed-off-by: Khem Raj 
+---
+ mkspecs/common/gcc-base.conf | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mkspecs/common/gcc-base.conf b/mkspecs/common/gcc-base.conf
+index 234f71d495..ee3da023e6 100644
+--- a/mkspecs/common/gcc-base.conf
 b/mkspecs/common/gcc-base.conf
+@@ -46,7 +46,7 @@ QMAKE_CFLAGS_DEBUG += -g
+ QMAKE_CFLAGS_SHLIB += $$QMAKE_CFLAGS_PIC
+ QMAKE_CFLAGS_STATIC_LIB+= $$QMAKE_CFLAGS_PIC
+ QMAKE_CFLAGS_APP   += $$QMAKE_CFLAGS_PIC
+-QMAKE_CFLAGS_ISYSTEM= -isystem
++QMAKE_CFLAGS_ISYSTEM= -I
+ QMAKE_CFLAGS_YACC  += -Wno-unused -Wno-parentheses
+ QMAKE_CFLAGS_HIDESYMS  += -fvisibility=hidden
+ QMAKE_CFLAGS_EXCEPTIONS_OFF += -fno-exceptions
+-- 
+2.16.1
+
diff --git a/recipes-qt/qt5/qtbase_git.bb b/recipes-qt/qt5/qtbase_git.bb
index 522e261..e495b8c 100644
--- a/recipes-qt/qt5/qtbase_git.bb
+++ b/recipes-qt/qt5/qtbase_git.bb
@@ -30,6 +30,7 @@ SRC_URI += "\
 file://0009-Add-OE-specific-specs-for-clang-compiler.patch \
 file://0010-linux-clang-Invert-conditional-for-defining-QT_SOCKL.patch \
 file://0011-tst_qlocale-Enable-QT_USE_FENV-only-on-glibc.patch \
+file://0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch \
 "
 
 # LGPL-3.0 is used only in src/plugins/platforms/android/extract.cpp
-- 
2.16.2

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-qt5][PATCH 2/2] qtbase: Add packageconfigs for renameat2 and getentropy use

[Khem Raj]

These features depend on underlying syscall support in kernel
and if older kernels are in use, then we can have a knob to
turn them off.

Signed-off-by: Khem Raj 
---
 recipes-qt/qt5/qtbase_git.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/recipes-qt/qt5/qtbase_git.bb b/recipes-qt/qt5/qtbase_git.bb
index e495b8c..843648f 100644
--- a/recipes-qt/qt5/qtbase_git.bb
+++ b/recipes-qt/qt5/qtbase_git.bb
@@ -71,7 +71,7 @@ PACKAGECONFIG_DISTRO ?= ""
 PACKAGECONFIG_RELEASE ?= "release"
 # This is in qt5.inc, because qtwebkit-examples are using it to enable 
ca-certificates dependency
 # PACKAGECONFIG_OPENSSL ?= "openssl"
-PACKAGECONFIG_DEFAULT ?= "dbus udev evdev widgets tools libs freetype tests"
+PACKAGECONFIG_DEFAULT ?= "dbus udev evdev widgets tools libs freetype tests 
renameat2 getentropy"
 
 PACKAGECONFIG ?= " \
 ${PACKAGECONFIG_RELEASE} \
@@ -146,6 +146,10 @@ PACKAGECONFIG[widgets] = "-widgets,-no-widgets"
 PACKAGECONFIG[libproxy] = "-libproxy,-no-libproxy,libproxy"
 PACKAGECONFIG[libinput] = "-libinput,-no-libinput,libinput"
 PACKAGECONFIG[journald] = "-journald,-no-journald,systemd"
+# needs kernel 3.16+
+PACKAGECONFIG[renameat2] = "-feature-renameat2,-no-feature-renameat2,"
+# needs kernel 3.17+
+PACKAGECONFIG[getentropy] = "-feature-getentropy,-no-feature-getentropy,"
 
 QT_CONFIG_FLAGS_GOLD = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 
'-use-gold-linker', '-no-use-gold-linker', d)}"
 QT_CONFIG_FLAGS += " \
-- 
2.16.2

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] libtalloc failure due to waf

[Joshua Watt]

On Wed, Feb 21, 2018 at 8:48 PM, Tim Orling
 wrote:
> Still failing for me, which is a show stopper. :(

Armin has it in his testing branch for the next master update, so
hopefully it will pulled in soon.

>
>> On Feb 21, 2018, at 5:36 PM, Denys Dmytriyenko  wrote:
>>
>> Any updates on this one yet? Thanks.
>>
>> On Fri, Feb 16, 2018 at 02:18:32PM -0800, Tim Orling wrote:
>>> Expediting the fix is greatly appreciated.
>>>
>>> Thank you!
>>>
>>> --Tim
>>>
>>> On Fri, Feb 16, 2018 at 1:00 PM, Joshua Watt  wrote:
>>>
 On Fri, 2018-02-16 at 21:55 +0100, Martin Jansa wrote:
> Don't you want to update that one to use the new function from utils
> instead of re-introducing get_waf_parallel_make?

  yes. I guess I can do that now. It didn't exist when I wrote the
 first version of this patch
> On Fri, Feb 16, 2018 at 9:18 PM, Joshua Watt 
> wrote:
>> On Fri, 2018-02-16 at 21:08 +0100, Martin Jansa wrote:
>>> And now it will fail to parse as well:
>>> http://git.openembedded.org/openembedded-core/commit/?id=ccd1142d
>>> 22b31ed85d8823b1bc9e11ccfd72b61f
>>>
>>> removed get_waf_parallel_make from waf.bbclass, so now all waf-
>>> samba.bbclass users will fail to parse with:
>>
>> http://lists.openembedded.org/pipermail/openembedded-devel/2018-Feb
>> ruary/116701.html will fix that as well We probably need to
>> speed along that getting merged.
>> Armin can you help with that?
>>
>> This patch should resolve all of the waf issues that have been
>> discussed here, with exception of the one improvement proposed by
>> Denys. While it should probably be improved, I don't beleive it
>> actually affects any recipes (some please give me an example if I
>> am wrong).
>>
>> Sorry for the churn. Hopefull this will be better in the future
>> since waf and samba-waf are no longer tied together.
>>
>> Joshua Watt
>>> bb.data_smart.ExpansionError: Failure expanding variable
>>> do_compile, expression was
>>>python ./buildtools/bin/waf ${@get_waf_parallel_make(d)}
>>> which triggered exception NameError: name
>>> 'get_waf_parallel_make' is not defined
>>> On Fri, Feb 16, 2018 at 9:45 AM, Martin Jansa >> .com> wrote:
 Check this thread:
 http://lists.openembedded.org/pipermail/openembedded-commits/20
 18-January/218460.html

 but my patch wasn't merged:
 http://lists.openembedded.org/pipermail/openembedded-core/2018-
 January/146974.html
 only the one from Joshua.


 The original issue is still in rocko as well, the backported
 waf change doesn't work and causes useless warning.

 Either the "waf.bbclass: explicitly pass bindir and libdir if
 supported" should be reverted in rocko or all fixes for this
 should be backported to rocko once they are all in oe-core and
 meta-oe master.

 Regards,

 On Fri, Feb 16, 2018 at 2:03 AM, Denys Dmytriyenko  wrote:
> On Thu, Feb 15, 2018 at 06:37:11PM -0600, Joshua Watt wrote:
>
>> On Feb 15, 2018 17:42, "Denys Dmytriyenko" > wrote:
>
>>
>
>> On Thu, Feb 15, 2018 at 03:30:06PM -0800, Khem Raj wrote:
>
>>> On Thu, Feb 15, 2018 at 3:24 PM, Denys Dmytriyenko  @denix.org>
>
>> wrote:
>
 On Thu, Feb 15, 2018 at 11:20:49PM +, Tim Orling
> wrote:
>
> Then why did ‘sudo dnf install waf’ get me past the
> error above? And
>
>> why
>
> does Fedora have a package for it?
>
>
>
> https://src.fedoraproject.org/rpms/waf
>
>
>
> Regardless, something broke.
>

>
 I thought so too. As waf.bbclass from oe-core looks for
> waf binary in
>
>> the root
>
 of the source package, I looked inside libtalloc 2.1.9
> and 2.1.10 and
>
>> neither
>
 of them have any "waf" files at the root. How was it
> working before?
>
>> What
>
 broke?
>
>>>
>
>>> its using waf-samba.bbclass, there is a patch floating
> for that
>
>>> https://patchwork.openembedded.org/patch/148046/
>
>>
>
>> So, it will fix libtalloc, but some other packages that
> still use
>
>> waf.bbclass
>
>> will keep on failing with an exception?
>
>>
>
>>
>
>> 

Re: [oe] libtalloc failure due to waf

[Tim Orling]

Still failing for me, which is a show stopper. :(

> On Feb 21, 2018, at 5:36 PM, Denys Dmytriyenko  wrote:
> 
> Any updates on this one yet? Thanks.
> 
> On Fri, Feb 16, 2018 at 02:18:32PM -0800, Tim Orling wrote:
>> Expediting the fix is greatly appreciated.
>> 
>> Thank you!
>> 
>> --Tim
>> 
>> On Fri, Feb 16, 2018 at 1:00 PM, Joshua Watt  wrote:
>> 
>>> On Fri, 2018-02-16 at 21:55 +0100, Martin Jansa wrote:
 Don't you want to update that one to use the new function from utils
 instead of re-introducing get_waf_parallel_make?
>>> 
>>>  yes. I guess I can do that now. It didn't exist when I wrote the
>>> first version of this patch
 On Fri, Feb 16, 2018 at 9:18 PM, Joshua Watt 
 wrote:
> On Fri, 2018-02-16 at 21:08 +0100, Martin Jansa wrote:
>> And now it will fail to parse as well:
>> http://git.openembedded.org/openembedded-core/commit/?id=ccd1142d
>> 22b31ed85d8823b1bc9e11ccfd72b61f
>> 
>> removed get_waf_parallel_make from waf.bbclass, so now all waf-
>> samba.bbclass users will fail to parse with:
> 
> http://lists.openembedded.org/pipermail/openembedded-devel/2018-Feb
> ruary/116701.html will fix that as well We probably need to
> speed along that getting merged.
> Armin can you help with that?
> 
> This patch should resolve all of the waf issues that have been
> discussed here, with exception of the one improvement proposed by
> Denys. While it should probably be improved, I don't beleive it
> actually affects any recipes (some please give me an example if I
> am wrong).
> 
> Sorry for the churn. Hopefull this will be better in the future
> since waf and samba-waf are no longer tied together.
> 
> Joshua Watt
>> bb.data_smart.ExpansionError: Failure expanding variable
>> do_compile, expression was
>>python ./buildtools/bin/waf ${@get_waf_parallel_make(d)}
>> which triggered exception NameError: name
>> 'get_waf_parallel_make' is not defined
>> On Fri, Feb 16, 2018 at 9:45 AM, Martin Jansa > .com> wrote:
>>> Check this thread:
>>> http://lists.openembedded.org/pipermail/openembedded-commits/20
>>> 18-January/218460.html
>>> 
>>> but my patch wasn't merged:
>>> http://lists.openembedded.org/pipermail/openembedded-core/2018-
>>> January/146974.html
>>> only the one from Joshua.
>>> 
>>> 
>>> The original issue is still in rocko as well, the backported
>>> waf change doesn't work and causes useless warning.
>>> 
>>> Either the "waf.bbclass: explicitly pass bindir and libdir if
>>> supported" should be reverted in rocko or all fixes for this
>>> should be backported to rocko once they are all in oe-core and
>>> meta-oe master.
>>> 
>>> Regards,
>>> 
>>> On Fri, Feb 16, 2018 at 2:03 AM, Denys Dmytriyenko >> .org> wrote:
 On Thu, Feb 15, 2018 at 06:37:11PM -0600, Joshua Watt wrote:
 
> On Feb 15, 2018 17:42, "Denys Dmytriyenko"  wrote:
 
> 
 
> On Thu, Feb 15, 2018 at 03:30:06PM -0800, Khem Raj wrote:
 
>> On Thu, Feb 15, 2018 at 3:24 PM, Denys Dmytriyenko >>> @denix.org>
 
> wrote:
 
>>> On Thu, Feb 15, 2018 at 11:20:49PM +, Tim Orling
 wrote:
 
 Then why did ‘sudo dnf install waf’ get me past the
 error above? And
 
> why
 
 does Fedora have a package for it?
 
 
 
 https://src.fedoraproject.org/rpms/waf
 
 
 
 Regardless, something broke.
 
>>> 
 
>>> I thought so too. As waf.bbclass from oe-core looks for
 waf binary in
 
> the root
 
>>> of the source package, I looked inside libtalloc 2.1.9
 and 2.1.10 and
 
> neither
 
>>> of them have any "waf" files at the root. How was it
 working before?
 
> What
 
>>> broke?
 
>> 
 
>> its using waf-samba.bbclass, there is a patch floating
 for that
 
>> https://patchwork.openembedded.org/patch/148046/
 
> 
 
> So, it will fix libtalloc, but some other packages that
 still use
 
> waf.bbclass
 
> will keep on failing with an exception?
 
> 
 
> 
 
> They shouldn't. I tested all the ones I could find. The way
 waf-samba uses
 
> waf is more of the exception than the rule Most
 projects will follow
 
> the waf.bbclass pattern of a wscript and waf in $S, but we
 can 

Re: [oe] Splitting meta-oe?

[Martin Hundebøll]

On 2018-02-21 14:57, Tom Rini wrote:

On Tue, Feb 20, 2018 at 09:10:25PM -0300, Otavio Salvador wrote:

On Tue, Feb 20, 2018 at 9:07 PM, Otavio Salvador
 wrote:

On Tue, Feb 20, 2018 at 3:52 PM, Richard Purdie
 wrote:

I could combo-layer pieces of meta-oe into poky but I'd imagine that
would create more problems than it would solve too and given the
general dislike of combo-layer, I think ultimately better layer tooling
would be a better answer and more acceptable to everyone.


Poky creates more problems then it solves


... send was too soon ...

Poky creates more problems then it solves.

  - it causes confusion
  - it avoids the urgency in adopting a setup script
  - it does not use the layers as we market as being a good thing

So adding more things to it, just makes it worse.

The setup script is more urgent to be discussed then splitting meta-oe.


I agree that a setup script of some sort (off the top of my head,
something that takes layer-names as input, checks vs a list,
fetches/clones, creates a wrapper around bitbake-layers to always add
them) should be a high priority.  I don't have a problem telling my
customers to clone meta-openembedded and then use the layers that are
needed in that specific project.  But it's painful to have a shell
for-loop in the docs we provide so they can setup a build.


Now that the discussion branched out a bit...

We would like better support for this too. Our setup uses a "manifest" 
repository with git submodules to setup the layers:


> yocto/
>   meta-poky/
>   meta-qt5/
>   meta-foo/
>   meta-bar/
>   conf/
>bblayers.conf
>local.conf
>   .gitmodules

With this setup, customers simply need to clone our yocto repo 
recursively, run `yocto/meta-poky/oe-init-build-env yocto` and then 
`bitbake image-recipe`.


But this is rather inflexible, as it requires the "yocto" folder to be 
the build folder to activate the config files...


We looked into putting the configs in "meta-foo/conf/*.conf.sample" and 
using TEMPLATECONF, but the "oe-init-build-env" script is rather picky 
about poky being the "top" directory.


I guess the oe-init-build-env script can be changed to look for 
.templateconf in any parent folder?


// Martin
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] libtalloc failure due to waf

[Denys Dmytriyenko]

Any updates on this one yet? Thanks.

On Fri, Feb 16, 2018 at 02:18:32PM -0800, Tim Orling wrote:
> Expediting the fix is greatly appreciated.
> 
> Thank you!
> 
> --Tim
> 
> On Fri, Feb 16, 2018 at 1:00 PM, Joshua Watt  wrote:
> 
> > On Fri, 2018-02-16 at 21:55 +0100, Martin Jansa wrote:
> > > Don't you want to update that one to use the new function from utils
> > > instead of re-introducing get_waf_parallel_make?
> >
> >  yes. I guess I can do that now. It didn't exist when I wrote the
> > first version of this patch
> > > On Fri, Feb 16, 2018 at 9:18 PM, Joshua Watt 
> > > wrote:
> > > > On Fri, 2018-02-16 at 21:08 +0100, Martin Jansa wrote:
> > > > > And now it will fail to parse as well:
> > > > > http://git.openembedded.org/openembedded-core/commit/?id=ccd1142d
> > > > > 22b31ed85d8823b1bc9e11ccfd72b61f
> > > > >
> > > > > removed get_waf_parallel_make from waf.bbclass, so now all waf-
> > > > > samba.bbclass users will fail to parse with:
> > > >
> > > > http://lists.openembedded.org/pipermail/openembedded-devel/2018-Feb
> > > > ruary/116701.html will fix that as well We probably need to
> > > > speed along that getting merged.
> > > > Armin can you help with that?
> > > >
> > > > This patch should resolve all of the waf issues that have been
> > > > discussed here, with exception of the one improvement proposed by
> > > > Denys. While it should probably be improved, I don't beleive it
> > > > actually affects any recipes (some please give me an example if I
> > > > am wrong).
> > > >
> > > > Sorry for the churn. Hopefull this will be better in the future
> > > > since waf and samba-waf are no longer tied together.
> > > >
> > > > Joshua Watt
> > > > > bb.data_smart.ExpansionError: Failure expanding variable
> > > > > do_compile, expression was
> > > > > python ./buildtools/bin/waf ${@get_waf_parallel_make(d)}
> > > > >  which triggered exception NameError: name
> > > > > 'get_waf_parallel_make' is not defined
> > > > > On Fri, Feb 16, 2018 at 9:45 AM, Martin Jansa  > > > > .com> wrote:
> > > > > > Check this thread:
> > > > > > http://lists.openembedded.org/pipermail/openembedded-commits/20
> > > > > > 18-January/218460.html
> > > > > >
> > > > > > but my patch wasn't merged:
> > > > > > http://lists.openembedded.org/pipermail/openembedded-core/2018-
> > > > > > January/146974.html
> > > > > > only the one from Joshua.
> > > > > >
> > > > > >
> > > > > > The original issue is still in rocko as well, the backported
> > > > > > waf change doesn't work and causes useless warning.
> > > > > >
> > > > > > Either the "waf.bbclass: explicitly pass bindir and libdir if
> > > > > > supported" should be reverted in rocko or all fixes for this
> > > > > > should be backported to rocko once they are all in oe-core and
> > > > > > meta-oe master.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > On Fri, Feb 16, 2018 at 2:03 AM, Denys Dmytriyenko  > > > > > .org> wrote:
> > > > > > > On Thu, Feb 15, 2018 at 06:37:11PM -0600, Joshua Watt wrote:
> > > > > > >
> > > > > > > > On Feb 15, 2018 17:42, "Denys Dmytriyenko"  > > > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > > On Thu, Feb 15, 2018 at 03:30:06PM -0800, Khem Raj wrote:
> > > > > > >
> > > > > > > > > On Thu, Feb 15, 2018 at 3:24 PM, Denys Dmytriyenko  > > > > > > @denix.org>
> > > > > > >
> > > > > > > > wrote:
> > > > > > >
> > > > > > > > > > On Thu, Feb 15, 2018 at 11:20:49PM +, Tim Orling
> > > > > > > wrote:
> > > > > > >
> > > > > > > > > >> Then why did ‘sudo dnf install waf’ get me past the
> > > > > > > error above? And
> > > > > > >
> > > > > > > > why
> > > > > > >
> > > > > > > > > >> does Fedora have a package for it?
> > > > > > >
> > > > > > > > > >>
> > > > > > >
> > > > > > > > > >> https://src.fedoraproject.org/rpms/waf
> > > > > > >
> > > > > > > > > >>
> > > > > > >
> > > > > > > > > >> Regardless, something broke.
> > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > > > > > > > I thought so too. As waf.bbclass from oe-core looks for
> > > > > > > waf binary in
> > > > > > >
> > > > > > > > the root
> > > > > > >
> > > > > > > > > > of the source package, I looked inside libtalloc 2.1.9
> > > > > > > and 2.1.10 and
> > > > > > >
> > > > > > > > neither
> > > > > > >
> > > > > > > > > > of them have any "waf" files at the root. How was it
> > > > > > > working before?
> > > > > > >
> > > > > > > > What
> > > > > > >
> > > > > > > > > > broke?
> > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > > > > its using waf-samba.bbclass, there is a patch floating
> > > > > > > for that
> > > > > > >
> > > > > > > > > https://patchwork.openembedded.org/patch/148046/
> > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > > So, it will fix libtalloc, but some other packages that
> > > > > > > still use
> > > > > > >
> > > > > > > > waf.bbclass
> > > > > > >
> > > > > > > > will keep on 

Re: [oe] [RESEND meta-python PATCH 2/2] python3-requests: Remove RDEPENDS on python3-misc

[Alejandro Enedino Hernandez Samaniego]

Hey Otavio,


Just to clarify that the misc package wasnt removed, it still exists, 
but with the rework


selectors was put on core, so your patch is fine, but what was removed 
was the


dependency on misc, not the package itself, just a technicality.


Cheers,


Alejandro


On 02/21/2018 11:21 AM, Otavio Salvador wrote:

The misc package has been removed when the python3 was reworked.

Tested using updatehub's uhu utility.

Signed-off-by: Otavio Salvador 
---

  meta-python/recipes-devtools/python/python3-requests_2.18.4.bb | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb 
b/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb
index d91d993bf..0a2410f85 100644
--- a/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb
+++ b/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb
@@ -1,5 +1,2 @@
  inherit setuptools3
  require python-requests.inc
-
-# Add the runtime depends for selectors.py
-RDEPENDS_${PN} += "${PYTHON_PN}-misc"


--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [RESEND meta-python PATCH 2/2] python3-requests: Remove RDEPENDS on python3-misc

[Otavio Salvador]

The misc package has been removed when the python3 was reworked.

Tested using updatehub's uhu utility.

Signed-off-by: Otavio Salvador 
---

 meta-python/recipes-devtools/python/python3-requests_2.18.4.bb | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb 
b/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb
index d91d993bf..0a2410f85 100644
--- a/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb
+++ b/meta-python/recipes-devtools/python/python3-requests_2.18.4.bb
@@ -1,5 +1,2 @@
 inherit setuptools3
 require python-requests.inc
-
-# Add the runtime depends for selectors.py
-RDEPENDS_${PN} += "${PYTHON_PN}-misc"
-- 
2.16.2

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Andreas Oberritter]

On Wed, 21 Feb 2018 15:58:17 +0100
Patrick Ohly  wrote:

> On Wed, 2018-02-21 at 14:14 +, Burton, Ross wrote:
> > > But that kind of mechanism seems highly prone to breakage and
> > > likely to
> > > be highly contentious even if it was shown to be reliable, so it
> > > may not
> > > get beyond a "that'd be nice" thing for me.
> > > 
> > > Unless someone else has already implemented it and I'm just not
> > > aware of
> > > how to use it?  :-)
> > >   
> > 
> > meta-freescale (iirc) does this, conditionally adds
> > sub-layers to BBLAYERS based on what other layers are already
> > enabled.  
> 
> The approach used by meta-freescale works with older releases.
> BBFILES_DYNAMIC [1] (supported by bitbake 1.36/Yocto 2.4) is a bit more
> robust.
> 
> [1] https://patchwork.openembedded.org/patch/140532/
> 

That's interesting. Is it possible to express dependencies on more than one
layer for a group of recipes with this mechanism?

Regards,
Andreas
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] OEDAM 2018 - Portland

[akuster808]

hello,

This is a friendly reminder regarding OEDAM this year in Portland. If
you are planning on attending, please add your name to the list

see https://www.openembedded.org/wiki/OEDAM_2018.


If you don't have write access to wiki,  send me your Name so I can add
you.  Also, as I understand it, some folks will be arriving late. Can
you please add you names and an {L} next to it. We are trying to get a
head count.


Kind regards,

Armin



-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [RESEND meta-python PATCH 1/2] python3-jsonschema: Remove RDEPENDS on python3-misc

[Otavio Salvador]

The misc package has been removed when the python3 was reworked.

Tested using updatehub's uhu utility.

Signed-off-by: Otavio Salvador 
---

 meta-python/recipes-devtools/python/python3-jsonschema_2.6.0.bb | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta-python/recipes-devtools/python/python3-jsonschema_2.6.0.bb 
b/meta-python/recipes-devtools/python/python3-jsonschema_2.6.0.bb
index 5aaee682b..926990747 100644
--- a/meta-python/recipes-devtools/python/python3-jsonschema_2.6.0.bb
+++ b/meta-python/recipes-devtools/python/python3-jsonschema_2.6.0.bb
@@ -1,6 +1,2 @@
 inherit pypi setuptools3
 require python-jsonschema.inc
-
-RDEPENDS_${PN} += " \
-${PYTHON_PN}-misc \
-"
-- 
2.16.2

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] State of the world, Failed tasks 2018-02-19

[akuster808]

== Failed tasks 2018-02-19 ==

INFO: jenkins-job.sh-1.8.43 Complete log available at 
http://logs.nslu2-linux.org/buildlogs/oe/world/sumo/log.report.20180221_044331.log

=== common (9) ===
* 
meta-openembedded/meta-networking/recipes-extended/iscsitarget/iscsitarget_1.4.20.3+svn502.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-protocols/tsocks/tsocks_1.8beta5.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-support/drbd/drbd_9.0.8-1.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-support/wireshark/wireshark_2.4.4.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-devtools/librcf/librcf_2.2.0.0.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-extended/tipcutils/tipcutils_git.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-graphics/dnfdragora/dnfdragora_git.bb:do_packagedata
* 
meta-openembedded/meta-oe/recipes-graphics/libyui/libyui-ncurses_git.bb:do_compile

=== common-x86 (1) ===
* 
meta-openembedded/meta-oe/recipes-support/vboxguestdrivers/vboxguestdrivers_5.1.26.bb:do_compile

=== qemuarm (8) ===
* 
meta-openembedded/meta-filesystems/recipes-utils/aufs-util/aufs-util_git.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-daemons/keepalived/keepalived_1.3.5.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-filter/ebtables/ebtables_2.0.10-4.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-protocols/openl2tp/openl2tp_1.8.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-benchmark/libc-bench/libc-bench_20110206.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb:do_compile
* 
openembedded-core/meta/recipes-core/glibc/glibc-locale_2.26.bb:do_package_qa
* openembedded-core/meta/recipes-sato/webkit/webkitgtk_2.18.6.bb:do_compile

=== qemuarm64 (4) ===
* 
meta-openembedded/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc_2.0.2.bb:do_configure
* 
meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_2.0.5.bb:do_compile
* 
openembedded-core/meta/recipes-kernel/kexec/kexec-tools_2.0.16.bb:do_compile
* 
openembedded-core/meta/recipes-sato/webkit/webkitgtk_2.18.6.bb:do_configure

=== qemux86 (18) ===
* 
meta-browser/recipes-browser/chromium/chromium-ozone-wayland_64.0.3274.0.r517731.igalia.1.bb:do_compile
* 
meta-browser/recipes-browser/chromium/chromium-x11_64.0.3282.167.bb:do_patch
* meta-browser/recipes-browser/firefox/firefox_45.9.0esr.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-connectivity/rdist/rdist_6.1.5.bb:do_package
* 
meta-openembedded/meta-networking/recipes-daemons/opensaf/opensaf_5.18.02.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.3.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-netkit/netkit-rsh/netkit-rsh_0.17.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-netkit/netkit-rusers/netkit-rusers_0.17.bb:do_compile
* 
meta-openembedded/meta-networking/recipes-netkit/netkit-telnet/netkit-telnet_0.17.bb:do_configure
* meta-openembedded/meta-oe/recipes-connectivity/umip/umip_1.0.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb:do_compile
* meta-openembedded/meta-oe/recipes-devtools/pm-qa/pm-qa_git.bb:do_compile
* meta-openembedded/meta-oe/recipes-kernel/crash/crash_7.2.0.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-kernel/minicoredumper/minicoredumper_2.0.0.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-multimedia/alsa/alsa-oss_1.0.28.bb:do_compile
* openembedded-core/meta/recipes-graphics/cogl/cogl-1.0_1.22.2.bb:do_compile
* 
openembedded-core/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.4.bb:do_compile
* openembedded-core/meta/recipes-multimedia/x264/x264_git.bb:do_package_qa

=== qemux86_64 (1) ===
* meta-openembedded/meta-oe/recipes-graphics/glm/glm_0.9.8.5.bb:do_compile

=== Number of failed tasks (80) ===
{| class=wikitable
|-
|| qemuarm  || 17|| 
http://logs.nslu2-linux.org/buildlogs/oe/world/sumo/log.world.qemuarm.20180218_142004.log/
 || http://errors.yoctoproject.org/Errors/Build/53665/
|-
|| qemuarm64|| 19|| 
http://logs.nslu2-linux.org/buildlogs/oe/world/sumo/log.world.qemuarm64.20180219_155544.log/
 || http://errors.yoctoproject.org/Errors/Build/53752/
|-
|| qemux86  || 28|| 
http://logs.nslu2-linux.org/buildlogs/oe/world/sumo/log.world.qemux86.20180218_142004.log/
 || http://errors.yoctoproject.org/Errors/Build/53664/
|-
|| qemux86_64   || 16|| 
http://logs.nslu2-linux.org/buildlogs/oe/world/sumo/log.world.qemux86-64.20180219_152126.log/
 || http://errors.yoctoproject.org/Errors/Build/53753/
|}

=== PNBLACKLISTs (0) ===

=== QA issues (6) ===
{| class=wikitable
!| Count||Issue
|-
||0 ||already-stripped
|-
||0 ||build-deps
|-

Re: [oe] [meta-qt5][PATCH] qtbase: Replace -isystem with -I

[Khem Raj]

On 2/21/18 11:55 AM, Denys Dmytriyenko wrote:
> On Tue, Feb 20, 2018 at 10:20:03PM -0800, Khem Raj wrote:
>> i can still see it with 5.10.1
>>
>>  from
>> /mnt/a/zonit/oe-build/build/tmp/work/aarch64-bec-linux/qtbase/5.10.1+gitAUTOINC+6c6ace9d23-r0/git/src/gui/kernel/qgenericpluginfactory.cpp:40:
>> /mnt/a/zonit/oe-build/build/tmp/work/aarch64-bec-linux/qtbase/5.10.1+gitAUTOINC+6c6ace9d23-r0/recipe-sysroot/usr/include/c++/7.3.0/cstdlib:75:15:
>> fatal error: stdlib.h: No such file or directory
>>  #include_next 
>>^~
>> compilation terminated.
>> make[2]: *** [Makefile:11592: .obj/qgenericpluginfactory.o] Error 1
>> make[2]: Leaving directory
>> '/mnt/a/zonit/oe-build/build/tmp/work/aarch64-bec-linux/qtbase/5.10.1+gitAUTOINC+6c6ace9d23-r0/build/src/gui'
>>
>> On Fri, Feb 16, 2018 at 6:35 PM, Khem Raj  wrote:
>>> On Fri, Feb 16, 2018 at 3:08 PM, Denys Dmytriyenko  wrote:
 On Fri, Feb 16, 2018 at 10:59:39PM +, Khem Raj wrote:
> I am using arch Linux for host distro and security flags enabled May be
> that is something

 Could be... I'm on Ubuntu 16.04.
>>>
>>> maybe you can try to enable security flags and see if you see it
> 
> Do you have any specifics regarding enabling security flags?
> 

add

require conf/distro/include/security_flags.inc

in local.conf
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-qt5][PATCH] qtbase: Replace -isystem with -I

[Denys Dmytriyenko]

On Tue, Feb 20, 2018 at 10:20:03PM -0800, Khem Raj wrote:
> i can still see it with 5.10.1
> 
>  from
> /mnt/a/zonit/oe-build/build/tmp/work/aarch64-bec-linux/qtbase/5.10.1+gitAUTOINC+6c6ace9d23-r0/git/src/gui/kernel/qgenericpluginfactory.cpp:40:
> /mnt/a/zonit/oe-build/build/tmp/work/aarch64-bec-linux/qtbase/5.10.1+gitAUTOINC+6c6ace9d23-r0/recipe-sysroot/usr/include/c++/7.3.0/cstdlib:75:15:
> fatal error: stdlib.h: No such file or directory
>  #include_next 
>^~
> compilation terminated.
> make[2]: *** [Makefile:11592: .obj/qgenericpluginfactory.o] Error 1
> make[2]: Leaving directory
> '/mnt/a/zonit/oe-build/build/tmp/work/aarch64-bec-linux/qtbase/5.10.1+gitAUTOINC+6c6ace9d23-r0/build/src/gui'
> 
> On Fri, Feb 16, 2018 at 6:35 PM, Khem Raj  wrote:
> > On Fri, Feb 16, 2018 at 3:08 PM, Denys Dmytriyenko  wrote:
> >> On Fri, Feb 16, 2018 at 10:59:39PM +, Khem Raj wrote:
> >>> I am using arch Linux for host distro and security flags enabled May be
> >>> that is something
> >>
> >> Could be... I'm on Ubuntu 16.04.
> >
> > maybe you can try to enable security flags and see if you see it

Do you have any specifics regarding enabling security flags?
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Patrick Ohly]

On Tue, 2018-02-20 at 18:52 +, Richard Purdie wrote:
> Even once we do that, we (as in YP) can't send out a clear message
> about what we're testing and users will clone meta-oe and expect
> everything to work. So right now I do have problems trying to get to
> a point where YP can use meta-oe effectively.

We had the same issue in refkit: the bblayers.conf.sample enabled a
large amount of layers, but the distro itself only needed and could
test only a subset of the recipes in those layers.

We solved this with supported-recipes.bbclass [1] and an explicit list
of recipes that were considered part of the distro [2] and thus got
tested. A "bitbake world" only builds those recipes. Users of the
distro could enable additional recipes, but then knew that they were on
their own regarding those.

[1] 
https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/classes/supported-recipes.bbclass
[2] 
https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit/conf/distro/include/refkit-supported-recipes.txt

Note that this mechanism also allowed us to support only a subset of,
for example, OE-core: we settled on systemd as the only supported init
system, so sysvinit wasn't listed as supported. This is something that
cannot realistically be achieved by splitting up layers and/or repos
containing layers.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-qt4] Cmake Could NOT find Qt4, missing: QT_MOC_EXECUTABLE

[Måns Zigher]

Shouldn't it actually point to sysroot-components? Even if the directory
would actually exists and containing the moc4 then what if the recipe is
cleared after building qt4-native it would break. Is the problem that
qt4-native is actually broken for rocko?

BR
Mans Zigher

2018-02-21 15:51 GMT+01:00 Måns Zigher :

> After some more investigation I realized that qmake is actually detected
> correctly the problem is that when running qmake2 -query I get the
> following results
>
> qmake2 -query
>
> QT_INSTALL_PREFIX:/home/build/tmp/work/x86_64-linux/qt4-nati
> ve/4.8.7-r0/recipe-sysroot-native/usr
>
>
> QT_INSTALL_DATA:/home/build/tmp/work/x86_64-linux/qt4-native
> /4.8.7-r0/recipe-sysroot-native/usr/share/qt4
>
>
> QT_INSTALL_DOCS:/home/build/tmp/work/x86_64-linux/qt4-native
> /4.8.7-r0/recipe-sysroot-native/usr/share/doc/qt4
>
>
> QT_INSTALL_HEADERS:/home/build/tmp/work/x86_64-linux/qt4-
> native/4.8.7-r0/recipe-sysroot-native/usr/include/qt4
>
>
> QT_INSTALL_LIBS:/home/build/tmp/work/x86_64-linux/qt4-native
> /4.8.7-r0/recipe-sysroot-native/usr/lib
>
>
> QT_INSTALL_BINS:/home/build/tmp/work/x86_64-linux/qt4-native
> /4.8.7-r0/recipe-sysroot-native/usr/bin
>
>
> QT_INSTALL_PLUGINS:/home/build/tmp/work/x86_64-linux/qt4-
> native/4.8.7-r0/recipe-sysroot-native/usr/lib/qt4/plugins
>
>
> QT_INSTALL_IMPORTS:/home/build/tmp/work/x86_64-linux/qt4-
> native/4.8.7-r0/recipe-sysroot-native/usr/lib/qt4/imports
>
>
> QT_INSTALL_TRANSLATIONS:/home/build/tmp/work/x86_64-linux/qt
> 4-native/4.8.7-r0/recipe-sysroot-native/usr/share/qt4/translations
>
>
> QT_INSTALL_CONFIGURATION:/home/build/tmp/work/x86_64-linux/
> qt4-native/4.8.7-r0/recipe-sysroot-native/etc/qt4
>
>
> QT_INSTALL_EXAMPLES:/home/build/tmp/work/x86_64-linux/qt4-
> native/4.8.7-r0/recipe-sysroot-native/usr/bin/qt4/examples
>
>
> QT_INSTALL_DEMOS:/home/build/tmp/work/x86_64-linux/qt4-nativ
> e/4.8.7-r0/recipe-sysroot-native/usr/bin/qt4/demos
>
>
> QMAKE_MKSPECS:/home/build/tmp/work/x86_64-linux/qt4-native/4
> .8.7-r0/recipe-sysroot-native/usr/share/qt4/mkspecs
>
>
> QMAKE_VERSION:2.01a
> QT_VERSION:4.8.7
>
> QT_INSTALL_BINS:/home/build/tmp/work/x86_64-linux/qt4-native
> /4.8.7-r0/recipe-sysroot-native/usr/bin is a directory that is none
> existing.
>
> BR
> Mans Zigher
>
>
> 2018-02-21 13:13 GMT+01:00 Måns Zigher :
>
>> When running devshell I can verify that echo $PATH includes the
>> recipe-sysroot-native dir and if I run "whereis qmake2" the
>> recipe-sysroot-native dir appears. So the question remains why is CMake not
>> detecting the binaries?
>>
>> BR
>> Mans Zigher
>>
>> 2018-02-21 13:02 GMT+01:00 Måns Zigher :
>>
>>> Hi,
>>>
>>> I am trying to build a native QT application that is required when
>>> generating the image. The recipe is depending on qt4-native and i am using
>>> poky version rocko. The application is using CMake which is producing the
>>> following error
>>>
>>> | -- Looking for Q_WS_MAC - not found
>>> | CMake Error at recipe-sysroot-native/usr/shar
>>> e/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
>>>
>>> |   Could NOT find Qt4 (missing: QT_MOC_EXECUTABLE QT_RCC_EXECUTABLE
>>> |   QT_UIC_EXECUTABLE) (found version "4.8.7")
>>> | Call Stack (most recent call first):
>>> |   
>>> recipe-sysroot-native/usr/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377
>>> (_FPHSA_FAILURE_MESSAGE)
>>> |   recipe-sysroot-native/usr/share/cmake-3.8/Modules/FindQt4.cmake:1326
>>> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>>> |   CMakeLists.txt:5 (find_package)
>>>
>>> When using jethro the recipe works fine. If I search for qmake2 in the
>>> build directory we get the following hits
>>>
>>> ./tmp/sysroots-components/x86_64/qt4-native/usr/bin/qmake2
>>> ./tmp/work/x86_64-linux/my-qt-application/0.1-r0/recipe-sysr
>>> oot-native/usr/bin/qmake2
>>> ./tmp/work/x86_64-linux/qt4-native/4.8.7-r0/sysroot-destdir/
>>> home/build/tmp/work/x86_64-linux/qt4-native/4.8.7-r0/recipe-
>>> sysroot-native/usr/bin/qmake2
>>>
>>> I would think that CMake should find qmake2 in the recipe-sysroot-native
>>> dir. Any help would be appreciated. How can I point CMake in the direction
>>> so it finds the qt tools.
>>>
>>> BR
>>> Måns Zigher
>>>
>>>
>>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Otavio Salvador]

On Wed, Feb 21, 2018 at 11:58 AM, Patrick Ohly  wrote:
> On Wed, 2018-02-21 at 14:14 +, Burton, Ross wrote:
>> > But that kind of mechanism seems highly prone to breakage and
>> > likely to
>> > be highly contentious even if it was shown to be reliable, so it
>> > may not
>> > get beyond a "that'd be nice" thing for me.
>> >
>> > Unless someone else has already implemented it and I'm just not
>> > aware of
>> > how to use it?  :-)
>> >
>>
>> meta-freescale (iirc) does this, conditionally adds
>> sub-layers to BBLAYERS based on what other layers are already
>> enabled.
>
> The approach used by meta-freescale works with older releases.
> BBFILES_DYNAMIC [1] (supported by bitbake 1.36/Yocto 2.4) is a bit more
> robust.
>
> [1] https://patchwork.openembedded.org/patch/140532/

That's nice; I will update our use for rocko and beyond! :-)

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Patrick Ohly]

On Wed, 2018-02-21 at 14:14 +, Burton, Ross wrote:
> > But that kind of mechanism seems highly prone to breakage and
> > likely to
> > be highly contentious even if it was shown to be reliable, so it
> > may not
> > get beyond a "that'd be nice" thing for me.
> > 
> > Unless someone else has already implemented it and I'm just not
> > aware of
> > how to use it?  :-)
> > 
> 
> meta-freescale (iirc) does this, conditionally adds
> sub-layers to BBLAYERS based on what other layers are already
> enabled.

The approach used by meta-freescale works with older releases.
BBFILES_DYNAMIC [1] (supported by bitbake 1.36/Yocto 2.4) is a bit more
robust.

[1] https://patchwork.openembedded.org/patch/140532/

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-qt4] Cmake Could NOT find Qt4, missing: QT_MOC_EXECUTABLE

[Måns Zigher]

After some more investigation I realized that qmake is actually detected
correctly the problem is that when running qmake2 -query I get the
following results

qmake2 -query

QT_INSTALL_PREFIX:/home/build/tmp/work/x86_64-linux/qt4-
native/4.8.7-r0/recipe-sysroot-native/usr


QT_INSTALL_DATA:/home/build/tmp/work/x86_64-linux/qt4-
native/4.8.7-r0/recipe-sysroot-native/usr/share/qt4


QT_INSTALL_DOCS:/home/build/tmp/work/x86_64-linux/qt4-
native/4.8.7-r0/recipe-sysroot-native/usr/share/doc/qt4


QT_INSTALL_HEADERS:/home/build/tmp/work/x86_64-linux/
qt4-native/4.8.7-r0/recipe-sysroot-native/usr/include/qt4


QT_INSTALL_LIBS:/home/build/tmp/work/x86_64-linux/qt4-
native/4.8.7-r0/recipe-sysroot-native/usr/lib


QT_INSTALL_BINS:/home/build/tmp/work/x86_64-linux/qt4-
native/4.8.7-r0/recipe-sysroot-native/usr/bin


QT_INSTALL_PLUGINS:/home/build/tmp/work/x86_64-linux/
qt4-native/4.8.7-r0/recipe-sysroot-native/usr/lib/qt4/plugins


QT_INSTALL_IMPORTS:/home/build/tmp/work/x86_64-linux/
qt4-native/4.8.7-r0/recipe-sysroot-native/usr/lib/qt4/imports


QT_INSTALL_TRANSLATIONS:/home/build/tmp/work/x86_64-linux/
qt4-native/4.8.7-r0/recipe-sysroot-native/usr/share/qt4/translations


QT_INSTALL_CONFIGURATION:/home/build/tmp/work/x86_64-
linux/qt4-native/4.8.7-r0/recipe-sysroot-native/etc/qt4


QT_INSTALL_EXAMPLES:/home/build/tmp/work/x86_64-linux/
qt4-native/4.8.7-r0/recipe-sysroot-native/usr/bin/qt4/examples


QT_INSTALL_DEMOS:/home/build/tmp/work/x86_64-linux/qt4-
native/4.8.7-r0/recipe-sysroot-native/usr/bin/qt4/demos


QMAKE_MKSPECS:/home/build/tmp/work/x86_64-linux/qt4-native/
4.8.7-r0/recipe-sysroot-native/usr/share/qt4/mkspecs


QMAKE_VERSION:2.01a
QT_VERSION:4.8.7

QT_INSTALL_BINS:/home/build/tmp/work/x86_64-linux/qt4-
native/4.8.7-r0/recipe-sysroot-native/usr/bin is a directory that is none
existing.

BR
Mans Zigher


2018-02-21 13:13 GMT+01:00 Måns Zigher :

> When running devshell I can verify that echo $PATH includes the
> recipe-sysroot-native dir and if I run "whereis qmake2" the
> recipe-sysroot-native dir appears. So the question remains why is CMake not
> detecting the binaries?
>
> BR
> Mans Zigher
>
> 2018-02-21 13:02 GMT+01:00 Måns Zigher :
>
>> Hi,
>>
>> I am trying to build a native QT application that is required when
>> generating the image. The recipe is depending on qt4-native and i am using
>> poky version rocko. The application is using CMake which is producing the
>> following error
>>
>> | -- Looking for Q_WS_MAC - not found
>> | CMake Error at recipe-sysroot-native/usr/shar
>> e/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
>>
>> |   Could NOT find Qt4 (missing: QT_MOC_EXECUTABLE QT_RCC_EXECUTABLE
>> |   QT_UIC_EXECUTABLE) (found version "4.8.7")
>> | Call Stack (most recent call first):
>> |   
>> recipe-sysroot-native/usr/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377
>> (_FPHSA_FAILURE_MESSAGE)
>> |   recipe-sysroot-native/usr/share/cmake-3.8/Modules/FindQt4.cmake:1326
>> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>> |   CMakeLists.txt:5 (find_package)
>>
>> When using jethro the recipe works fine. If I search for qmake2 in the
>> build directory we get the following hits
>>
>> ./tmp/sysroots-components/x86_64/qt4-native/usr/bin/qmake2
>> ./tmp/work/x86_64-linux/my-qt-application/0.1-r0/recipe-sysr
>> oot-native/usr/bin/qmake2
>> ./tmp/work/x86_64-linux/qt4-native/4.8.7-r0/sysroot-destdir/
>> home/build/tmp/work/x86_64-linux/qt4-native/4.8.7-r0/recipe-
>> sysroot-native/usr/bin/qmake2
>>
>> I would think that CMake should find qmake2 in the recipe-sysroot-native
>> dir. Any help would be appreciated. How can I point CMake in the direction
>> so it finds the qt tools.
>>
>> BR
>> Måns Zigher
>>
>>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Tom Rini]

On Wed, Feb 21, 2018 at 11:00:27AM -0300, Otavio Salvador wrote:
> On Wed, Feb 21, 2018 at 10:57 AM, Tom Rini  wrote:
> > On Tue, Feb 20, 2018 at 09:10:25PM -0300, Otavio Salvador wrote:
> >> On Tue, Feb 20, 2018 at 9:07 PM, Otavio Salvador
> >>  wrote:
> >> > On Tue, Feb 20, 2018 at 3:52 PM, Richard Purdie
> >> >  wrote:
> >> >> I could combo-layer pieces of meta-oe into poky but I'd imagine that
> >> >> would create more problems than it would solve too and given the
> >> >> general dislike of combo-layer, I think ultimately better layer tooling
> >> >> would be a better answer and more acceptable to everyone.
> >> >
> >> > Poky creates more problems then it solves
> >>
> >> ... send was too soon ...
> >>
> >> Poky creates more problems then it solves.
> >>
> >>  - it causes confusion
> >>  - it avoids the urgency in adopting a setup script
> >>  - it does not use the layers as we market as being a good thing
> >>
> >> So adding more things to it, just makes it worse.
> >>
> >> The setup script is more urgent to be discussed then splitting meta-oe.
> >
> > I agree that a setup script of some sort (off the top of my head,
> > something that takes layer-names as input, checks vs a list,
> > fetches/clones, creates a wrapper around bitbake-layers to always add
> > them) should be a high priority.  I don't have a problem telling my
> > customers to clone meta-openembedded and then use the layers that are
> > needed in that specific project.  But it's painful to have a shell
> > for-loop in the docs we provide so they can setup a build.
> 
> I think we ought to start a thread about the tooling, but let's focus
> on meta-oe split here.

Agreed.  And to be clear, I'm another vote against splitting meta-oe.

-- 
Tom


signature.asc
Description: PGP signature
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Joe MacDonald]

[Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 09:20) Tom Rini wrote:

> On Wed, Feb 21, 2018 at 09:02:53AM -0500, Joe MacDonald wrote:
> > [Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 11:22) Martin Jansa wrote:
> > 
> > > There is good example of inter-layer dependencies from real world:
> > > http://lists.openembedded.org/pipermail/openembedded-devel/2017-February/111447.html
> > > 
> > > Do you want
> > > A) new git repository meta-libio-socket-ssl-perl so that meta-networking
> > > will depend on this on instead of whole meta-perl
> > > B) meta-ddclient which will probably depend on both meta-perl and
> > > meta-networking
> > > C) ddclient and its dependencies in meta-perl
> > > D) libio-socket-ssl-perl moved to oe-core, so that next time we can say
> > > that oe-core is just like old oe-classic just with a bit less stuff in it
> > > 
> > > Neither of these options is ideal, but meta-networking getting meta-perl
> > > dependency is the one which causes fewest issues to OE users.
> > 
> > Yeah, I've been thinking about this and trying to decide what is the
> > "right" thing to do here.  Because I already have added layer
> > dependencies in meta-networking that I didn't originally envision, so
> > what's one more that is, as you say, almost certainly in the majority of
> > consumers' projects anyway?  But it does force a new layer dependency on
> > consumers of the meta-networking layer who may not care about ddclient,
> > and I'd like to avoid that if possible.
> > 
> > Honestly, now that I'm back from my vacation, I think the right thing is
> > to add the dependency and then start thinking about a way to specify
> > layer dependencies with greater granularity than on a meta-layer basis.
> > Like, there's no question meta-networking depends on core.  It's
> > nonsense to think of it without that dependency.  But it'd be nice to be
> > able to specify a layer dependency that only exists if your project
> > includes specific recipes out of that layer.
> > 
> > But that kind of mechanism seems highly prone to breakage and likely to
> > be highly contentious even if it was shown to be reliable, so it may not
> > get beyond a "that'd be nice" thing for me.
> > 
> > Unless someone else has already implemented it and I'm just not aware of
> > how to use it?  :-)
> 
> One thing I've been thinking about is that some layers need more
> sub-layers.  Taking a very tiny peek into meta-networking, perhaps
> re-organize into meta-networking-core, meta-networking-iscsi,
> meta-networking-vpn, etc.  Or maybe that won't help with dependencies.
> But the need for layer X for a single recipe can sometimes I think be
> solved by re-thinking the layer.

I really like that idea.  We effectively started that with the netkit
stuff when Armin first submitted it, so making it more formal isn't a
big step anyway.

> All that said, it might be better instead to add something like
> RECIPE_LAYERDEPENDS so that for the one-or-two offs, the recipe will
> fail to build (and implement that similar to the logic in
> image-container.bbclass? so that you only get a failure on building that
> recipe rather than anything in the layer) ?

Yeah, that's kind of what I'd been thinking.  In the short term, though,
the reorg you suggested above sounds *very* appealing to me at first
glance.  Might be a "let's do both" situation.

-- 
-Joe MacDonald.
:wq


signature.asc
Description: PGP signature
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Tom Rini]

On Wed, Feb 21, 2018 at 09:02:53AM -0500, Joe MacDonald wrote:
> [Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 11:22) Martin Jansa wrote:
> 
> > There is good example of inter-layer dependencies from real world:
> > http://lists.openembedded.org/pipermail/openembedded-devel/2017-February/111447.html
> > 
> > Do you want
> > A) new git repository meta-libio-socket-ssl-perl so that meta-networking
> > will depend on this on instead of whole meta-perl
> > B) meta-ddclient which will probably depend on both meta-perl and
> > meta-networking
> > C) ddclient and its dependencies in meta-perl
> > D) libio-socket-ssl-perl moved to oe-core, so that next time we can say
> > that oe-core is just like old oe-classic just with a bit less stuff in it
> > 
> > Neither of these options is ideal, but meta-networking getting meta-perl
> > dependency is the one which causes fewest issues to OE users.
> 
> Yeah, I've been thinking about this and trying to decide what is the
> "right" thing to do here.  Because I already have added layer
> dependencies in meta-networking that I didn't originally envision, so
> what's one more that is, as you say, almost certainly in the majority of
> consumers' projects anyway?  But it does force a new layer dependency on
> consumers of the meta-networking layer who may not care about ddclient,
> and I'd like to avoid that if possible.
> 
> Honestly, now that I'm back from my vacation, I think the right thing is
> to add the dependency and then start thinking about a way to specify
> layer dependencies with greater granularity than on a meta-layer basis.
> Like, there's no question meta-networking depends on core.  It's
> nonsense to think of it without that dependency.  But it'd be nice to be
> able to specify a layer dependency that only exists if your project
> includes specific recipes out of that layer.
> 
> But that kind of mechanism seems highly prone to breakage and likely to
> be highly contentious even if it was shown to be reliable, so it may not
> get beyond a "that'd be nice" thing for me.
> 
> Unless someone else has already implemented it and I'm just not aware of
> how to use it?  :-)

One thing I've been thinking about is that some layers need more
sub-layers.  Taking a very tiny peek into meta-networking, perhaps
re-organize into meta-networking-core, meta-networking-iscsi,
meta-networking-vpn, etc.  Or maybe that won't help with dependencies.
But the need for layer X for a single recipe can sometimes I think be
solved by re-thinking the layer.

All that said, it might be better instead to add something like
RECIPE_LAYERDEPENDS so that for the one-or-two offs, the recipe will
fail to build (and implement that similar to the logic in
image-container.bbclass? so that you only get a failure on building that
recipe rather than anything in the layer) ?

-- 
Tom


signature.asc
Description: PGP signature
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Burton, Ross]

On 21 February 2018 at 14:02, Joe MacDonald 
wrote:

> Honestly, now that I'm back from my vacation, I think the right thing is
> to add the dependency and then start thinking about a way to specify
> layer dependencies with greater granularity than on a meta-layer basis.
> Like, there's no question meta-networking depends on core.  It's
> nonsense to think of it without that dependency.  But it'd be nice to be
> able to specify a layer dependency that only exists if your project
> includes specific recipes out of that layer.
>
> But that kind of mechanism seems highly prone to breakage and likely to
> be highly contentious even if it was shown to be reliable, so it may not
> get beyond a "that'd be nice" thing for me.
>
> Unless someone else has already implemented it and I'm just not aware of
> how to use it?  :-)
>

meta-freescale (iirc) does this, conditionally adds sub-layers to BBLAYERS
based on what other layers are already enabled.

Ross
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Joe MacDonald]

[Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 11:22) Martin Jansa wrote:

> There is good example of inter-layer dependencies from real world:
> http://lists.openembedded.org/pipermail/openembedded-devel/2017-February/111447.html
> 
> Do you want
> A) new git repository meta-libio-socket-ssl-perl so that meta-networking
> will depend on this on instead of whole meta-perl
> B) meta-ddclient which will probably depend on both meta-perl and
> meta-networking
> C) ddclient and its dependencies in meta-perl
> D) libio-socket-ssl-perl moved to oe-core, so that next time we can say
> that oe-core is just like old oe-classic just with a bit less stuff in it
> 
> Neither of these options is ideal, but meta-networking getting meta-perl
> dependency is the one which causes fewest issues to OE users.

Yeah, I've been thinking about this and trying to decide what is the
"right" thing to do here.  Because I already have added layer
dependencies in meta-networking that I didn't originally envision, so
what's one more that is, as you say, almost certainly in the majority of
consumers' projects anyway?  But it does force a new layer dependency on
consumers of the meta-networking layer who may not care about ddclient,
and I'd like to avoid that if possible.

Honestly, now that I'm back from my vacation, I think the right thing is
to add the dependency and then start thinking about a way to specify
layer dependencies with greater granularity than on a meta-layer basis.
Like, there's no question meta-networking depends on core.  It's
nonsense to think of it without that dependency.  But it'd be nice to be
able to specify a layer dependency that only exists if your project
includes specific recipes out of that layer.

But that kind of mechanism seems highly prone to breakage and likely to
be highly contentious even if it was shown to be reliable, so it may not
get beyond a "that'd be nice" thing for me.

Unless someone else has already implemented it and I'm just not aware of
how to use it?  :-)

-J.

> As mentioned
> before by few people, most builds for "real world products" are already
> including many layers, adding meta-perl to BBLAYERS (it's probably there
> already for other recipes) without the need to update other build setup
> like checking additional git repositories is simple and I don't see how it
> makes meta-oe to be like oe-classic. The layers still separate stuff and I
> don't need to include layers from where I don't need anything at all.
> 
> Smallest set of upstream layers we use at LGE already contains half of
> meta-oe repository:
> oe-core meta-gplv2 meta-oe meta-multimedia meta-networking meta-python
> meta-filesystems meta-qt5
> and around 8 internal layers, so it's far from oe-classic days and
> different builds for different products have different subset of layers.
> 
> For internal layers we also use only a few git repositories 12 layers in
> the main one, because it makes it easier to keep them all compatible with
> each other at all times (e.g. by triggering the CI for all products from
> each gerrit review for this single repository).
> 
> I'm not advocating for putting _everything_ into single git repository or
> even the use of combo-layer tool, but keeping the layers maintained by the
> same "organization" with the same update cycle makes things easier to
> maintain and easier to consume by others.
> 
> Regards,
> 
> On Wed, Feb 21, 2018 at 10:48 AM, Andrea Adami 
> wrote:
> 
> > On Wed, Feb 21, 2018 at 10:06 AM, Martin Jansa 
> > wrote:
> > >> I'm actually very worried about these (re)tired maintainers. If the
> > > layers were more independent it would allow some of the patch handling
> > > responsibilities and testing responsibilities to move to other people,
> > > reducing the load on those maintainers.
> > >
> > > Armin can update his own view, but for me the main issue wasn't the
> > "patch
> > > handling" part, but actually the lack of patches for the new issues
> > (often
> > > caused by new changes in oe-core).
> > >
> >
> > That's one point.
> > If I may add my experience as maintainer of two minor layers
> > (meta-handheld and meta-initramfs), I have to say there have been many
> > cases where an upgrade to oe-core did break one of these layers.
> > Just a variable rename for example...this fall-outs could have been
> > avoided if the oe-core dev would have spent a minute grepping the
> > repository,
> > Heh..now we have to define what is the public repository, which layers
> > have to be checked...
> >
> > And about layer interdependencies...well..it is very delicate.
> > For example meta-handheld, a BSP layer, must depend since some time on
> > meta-oe. Why? Because tslib was removed from oe-core.
> > This is ugly...here a more separated layering structure would help
> >
> > So I somehow feel we should refine what is in the repository but
> > absolutely not split it around.
> > Even, I think we should host all public layers 

Re: [oe] Splitting meta-oe?

[Otavio Salvador]

On Wed, Feb 21, 2018 at 10:57 AM, Tom Rini  wrote:
> On Tue, Feb 20, 2018 at 09:10:25PM -0300, Otavio Salvador wrote:
>> On Tue, Feb 20, 2018 at 9:07 PM, Otavio Salvador
>>  wrote:
>> > On Tue, Feb 20, 2018 at 3:52 PM, Richard Purdie
>> >  wrote:
>> >> I could combo-layer pieces of meta-oe into poky but I'd imagine that
>> >> would create more problems than it would solve too and given the
>> >> general dislike of combo-layer, I think ultimately better layer tooling
>> >> would be a better answer and more acceptable to everyone.
>> >
>> > Poky creates more problems then it solves
>>
>> ... send was too soon ...
>>
>> Poky creates more problems then it solves.
>>
>>  - it causes confusion
>>  - it avoids the urgency in adopting a setup script
>>  - it does not use the layers as we market as being a good thing
>>
>> So adding more things to it, just makes it worse.
>>
>> The setup script is more urgent to be discussed then splitting meta-oe.
>
> I agree that a setup script of some sort (off the top of my head,
> something that takes layer-names as input, checks vs a list,
> fetches/clones, creates a wrapper around bitbake-layers to always add
> them) should be a high priority.  I don't have a problem telling my
> customers to clone meta-openembedded and then use the layers that are
> needed in that specific project.  But it's painful to have a shell
> for-loop in the docs we provide so they can setup a build.

I think we ought to start a thread about the tooling, but let's focus
on meta-oe split here.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH 1/2] mraa: Update recipe to use v1.9.0

[Brendan Le Foll]

The musl endian patch has been merged upstream so is no longer needed

Signed-off-by: Brendan Le Foll 
---
 ...o_driver.c-include-endian.h-to-fix-musl-b.patch | 29 --
 meta-oe/recipes-extended/mraa/mraa_git.bb  |  8 +++---
 2 files changed, 3 insertions(+), 34 deletions(-)
 delete mode 100644 
meta-oe/recipes-extended/mraa/mraa/0001-examples-iio_driver.c-include-endian.h-to-fix-musl-b.patch

diff --git 
a/meta-oe/recipes-extended/mraa/mraa/0001-examples-iio_driver.c-include-endian.h-to-fix-musl-b.patch
 
b/meta-oe/recipes-extended/mraa/mraa/0001-examples-iio_driver.c-include-endian.h-to-fix-musl-b.patch
deleted file mode 100644
index 401949e2e..0
--- 
a/meta-oe/recipes-extended/mraa/mraa/0001-examples-iio_driver.c-include-endian.h-to-fix-musl-b.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From 6c2649718fc9818da0d602a0b4767ea21a367e9e Mon Sep 17 00:00:00 2001
-From: Tim Orling 
-Date: Sat, 27 Jan 2018 02:06:36 -0800
-Subject: [PATCH] examples/iio_driver.c: include endian.h to fix musl build
-
-* be16toh and le16toh are defined in endian.h
-
-Upstream-Status: Pending
-
-Signed-off-by: Tim Orling 

- examples/iio_driver.c | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/examples/iio_driver.c b/examples/iio_driver.c
-index c5a0181..e3dc438 100644
 a/examples/iio_driver.c
-+++ b/examples/iio_driver.c
-@@ -23,6 +23,7 @@
-  */
- 
- #include 
-+#include 
- #include "mraa/iio.h"
- 
- static void
--- 
-2.13.6
-
diff --git a/meta-oe/recipes-extended/mraa/mraa_git.bb 
b/meta-oe/recipes-extended/mraa/mraa_git.bb
index e1d593cbe..16883be3a 100644
--- a/meta-oe/recipes-extended/mraa/mraa_git.bb
+++ b/meta-oe/recipes-extended/mraa/mraa_git.bb
@@ -3,15 +3,13 @@ HOMEPAGE = "https://github.com/intel-iot-devkit/mraa;
 SECTION = "libs"
 
 LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://COPYING;md5=66493d54e65bfc12c7983ff2e884f37f"
+LIC_FILES_CHKSUM = "file://COPYING;md5=4b92a3b497d7943042a6db40c088c3f2"
 
-SRCREV = "8ddbcde84e2d146bc0f9e38504d6c89c14291480"
-PV = "1.7.0-git${SRCPV}"
+SRCREV = "fbb7d9232067eac3f4508a37a8f7ea0c4fcebacb"
+PV = "1.9.0-git${SRCPV}"
 
 SRC_URI = "git://github.com/intel-iot-devkit/${BPN}.git;protocol=http"
 
-SRC_URI_append_libc-musl = " 
file://0001-examples-iio_driver.c-include-endian.h-to-fix-musl-b.patch"
-
 S = "${WORKDIR}/git"
 
 # CMakeLists.txt checks the architecture, only x86 and ARM supported for now
-- 
2.16.2

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH 2/2] upm: Update recipe to use v1.6.0

[Brendan Le Foll]

ads1x15 patch is no longer required as it has been merged upstream

Signed-off-by: Brendan Le Foll 
---
 ...15-fixed-case-logic-in-getThresh-function.patch | 54 --
 meta-oe/recipes-extended/upm/upm_git.bb|  5 +-
 2 files changed, 2 insertions(+), 57 deletions(-)
 delete mode 100644 
meta-oe/recipes-extended/upm/files/ads1x15-fixed-case-logic-in-getThresh-function.patch

diff --git 
a/meta-oe/recipes-extended/upm/files/ads1x15-fixed-case-logic-in-getThresh-function.patch
 
b/meta-oe/recipes-extended/upm/files/ads1x15-fixed-case-logic-in-getThresh-function.patch
deleted file mode 100644
index c617d14a1..0
--- 
a/meta-oe/recipes-extended/upm/files/ads1x15-fixed-case-logic-in-getThresh-function.patch
+++ /dev/null
@@ -1,54 +0,0 @@
-From c64d04d084f47b4cb3e1cdee6e96348fcc6a756e Mon Sep 17 00:00:00 2001
-From: Mihai Tudor Panu 
-Date: Tue, 30 May 2017 15:14:09 -0700
-Subject: [PATCH 1/1] ads1x15: fixed case logic in getThresh() function
-
-Signed-off-by: Mihai Tudor Panu 
-
-Upstream-Status: Backported [c64d04d084f47b4cb3e1cdee6e96348fcc6a756e]
-
-Signed-off-by: Patrick Ohly 
-

- src/ads1x15/ads1x15.cxx | 4 ++--
- src/ads1x15/ads1x15.hpp | 2 +-
- 2 files changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/src/ads1x15/ads1x15.cxx b/src/ads1x15/ads1x15.cxx
-index 35782709..47701b2a 100644
 a/src/ads1x15/ads1x15.cxx
-+++ b/src/ads1x15/ads1x15.cxx
-@@ -116,7 +116,7 @@ ADS1X15::setContinuous(bool mode){
- 
- float
- ADS1X15::getThresh(ADSTHRESH reg){
-- if( THRESH_HIGH && THRESH_LOW) return getLastSample(reg);
-+ if(reg == THRESH_HIGH || reg == THRESH_LOW) return getLastSample(reg);
-  else return 0.0;
- }
- 
-@@ -137,7 +137,7 @@ ADS1X15::setThresh(ADSTHRESH reg, float value){
-  case 2:
-  case 3:
-   set_value = value / getMultiplier();
-- set_value = set_value << m_bitShift;
-+  set_value = set_value << m_bitShift;
-   if(i2c->writeWordReg(reg, swapWord(set_value)) != mraa::SUCCESS){
- throw std::runtime_error(std::string(__FUNCTION__) + ": 
I2c.write() failed");
- return;
-diff --git a/src/ads1x15/ads1x15.hpp b/src/ads1x15/ads1x15.hpp
-index 7524572d..efd8c8ec 100644
 a/src/ads1x15/ads1x15.hpp
-+++ b/src/ads1x15/ads1x15.hpp
-@@ -390,7 +390,7 @@ namespace upm {
-  * @param reg ADSTHRES enum value.
-  * Returns 0.0 unless THRESH_HIGH or THRESH_LOW requested.
-  */
--float getThresh(ADSTHRESH reg = THRESH_LOW);
-+float getThresh(ADSTHRESH reg = THRESH_DEFAULT);
- 
- /**
-  * Sets threshold levels or configures for conversion ready
--- 
-2.11.0
-
diff --git a/meta-oe/recipes-extended/upm/upm_git.bb 
b/meta-oe/recipes-extended/upm/upm_git.bb
index a5c2bb321..d742a5e46 100644
--- a/meta-oe/recipes-extended/upm/upm_git.bb
+++ b/meta-oe/recipes-extended/upm/upm_git.bb
@@ -7,12 +7,11 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=66493d54e65bfc12c7983ff2e884f37f"
 
 DEPENDS = "libjpeg-turbo mraa"
 
-SRCREV = "106b6c706268522ab0168a4ddb19e89ce832e084"
-PV = "1.3.0-git${SRCPV}"
+SRCREV = "cc7fec9ae0228add9011bf1c2cd5e0ca2ba0d4f0"
+PV = "1.6.0-git${SRCPV}"
 
 SRC_URI = " \
 git://github.com/intel-iot-devkit/${BPN}.git;protocol=http \
-file://ads1x15-fixed-case-logic-in-getThresh-function.patch \
 "
 
 S = "${WORKDIR}/git"
-- 
2.16.2

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-qt5] qtbase-native/qmake broken for 5.10?

[Andreas Müller]

On Tue, Feb 20, 2018 at 10:54 AM, Andreas Müller
 wrote:
> Hi,
>
> giving Qt 5.10.0 a build I ran into the following issue detected by
> meta-qt5-extra/sddm build failure:
>
> Running native 'qmake -query' outputs
>
> | qmake -query
> | Empty filename passed to function
> | 
> QT_SYSROOT:/home/superandy/tmp/oe-core-glibc/work/x86_64-linux/qtbase-native/5.10.0+gitAUTOINC+50117d738a-r0/recipe-sysroot-native
> | ...
>
> ask for a certain property e.g QT_INSTALL_IMPORTS (this is what sddm
> does during build):
>
> | qmake -query QT_INSTALL_IMPORTS
> | Empty filename passed to function
> | 
> /home/superandy/tmp/oe-core-glibc/work/x86_64-linux/qtbase-native/5.10.0+gitAUTOINC+50117d738a-r0/recipe-sysroot-native/home/superandy/tmp/oe-core-glibc/work/x86_64-linux/qtbase-native/5.10.0+gitAUTOINC+50117d738a-r0/recipe-sysroot-native/usr/lib/qt5/imports
>
> First line always reports 'Empty filename passed to function' which is
> not exactly useful when expecting a path.
>
> I've searched the web without success for this so I decided to start
> debugging. Due to standard optimization most interesting variables are
> optimized out :(
>
> So before I rebuild qtbase-native without optimization and debug again
> I thought there might be someone here knowing something helpful
> regarding this issue.
>
> Thanks in advance
>
Fixed for sddm:
sddm is a bit special: It asks qmake from within cmake for paths.
Debugging showed that environment OE_QMAKE_QTCONF_PATH was missing.
Exporting this in sddm recipe did the job.

See qtbase source:

QSettings *QLibraryInfoPrivate::findConfiguration()
{
#ifdef QT_BUILD_QMAKE
QByteArray config = getenv("OE_QMAKE_QTCONF_PATH");
QString qtconfig = QFile::decodeName(config);
if(!QFile::exists(qtconfig))<-- This caused "Empty
filename passed to function"
...

Seems qmake-native 5.9 behaved differently here...

Thinking this more over I wonder if there might be another common
place for exporting OE_QMAKE_QTCONF_PATH. How about
qmake5_paths.bbclass?

Andreas
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Otavio Salvador]

On Wed, Feb 21, 2018 at 10:55 AM, Bruce Ashfield
 wrote:
> On Wed, Feb 21, 2018 at 8:45 AM, Joe MacDonald  
> wrote:
>> [Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 09:49) Martin Jansa wrote:
>>
>>> > I need an updated python- package for an unrelated package
>>>
>>> And how far will you go?
>>>
>>> If you want just newer python- and nothing else, will you take other
>>> changes to other python-* recipes from meta-python layer? There is a lot of
>>> recipes there, if you're so picky about updates, then you shouldn't update
>>> whole oe-core as well.
>>
>> It seems like this part is already settled, but it would seem to me that
>> this scenario, if I understand it correctly, is "I'm using oe-core and
>> see up-stream meta-oe/meta-somethingorother has an updated or new recipe
>> for something I want in my image but I don't want to do a pull on all of
>> meta-oe and potentially cause a huge rebuild of stuff I don't really
>> care about".
>>
>> That sounds like a problem better solved with 'git branch', 'git fetch'
>> and 'git cherry-pick' on the developer's side than breaking up meta-oe
>> across existing meta-boundaries.
>
> Agreed. I was just probing to see if anyone had ideas on how that could
> be managed by infrastructure, versus me mucking about.
>
> Maybe RP's thoughts on layer tooling or setup possibilities would help,
> but either way, I'll keep chugging along :D

I think this is a valid thing to discuss but not in this thread (as
well as for tooling and etc.).

Here I think we ought to focus in:

 Should we split meta-oe?

My vote is no! Yocto Project as a whole would benefit of people inside
of Yocto Project QA sending fixes for parse errors introduced by their
changes in OE-Core  and so I'd prefer to keep it as is.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Tom Rini]

On Tue, Feb 20, 2018 at 09:10:25PM -0300, Otavio Salvador wrote:
> On Tue, Feb 20, 2018 at 9:07 PM, Otavio Salvador
>  wrote:
> > On Tue, Feb 20, 2018 at 3:52 PM, Richard Purdie
> >  wrote:
> >> I could combo-layer pieces of meta-oe into poky but I'd imagine that
> >> would create more problems than it would solve too and given the
> >> general dislike of combo-layer, I think ultimately better layer tooling
> >> would be a better answer and more acceptable to everyone.
> >
> > Poky creates more problems then it solves
> 
> ... send was too soon ...
> 
> Poky creates more problems then it solves.
> 
>  - it causes confusion
>  - it avoids the urgency in adopting a setup script
>  - it does not use the layers as we market as being a good thing
> 
> So adding more things to it, just makes it worse.
> 
> The setup script is more urgent to be discussed then splitting meta-oe.

I agree that a setup script of some sort (off the top of my head,
something that takes layer-names as input, checks vs a list,
fetches/clones, creates a wrapper around bitbake-layers to always add
them) should be a high priority.  I don't have a problem telling my
customers to clone meta-openembedded and then use the layers that are
needed in that specific project.  But it's painful to have a shell
for-loop in the docs we provide so they can setup a build.

-- 
Tom


signature.asc
Description: PGP signature
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Bruce Ashfield]

On Wed, Feb 21, 2018 at 8:45 AM, Joe MacDonald  wrote:
> [Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 09:49) Martin Jansa wrote:
>
>> > I need an updated python- package for an unrelated package
>>
>> And how far will you go?
>>
>> If you want just newer python- and nothing else, will you take other
>> changes to other python-* recipes from meta-python layer? There is a lot of
>> recipes there, if you're so picky about updates, then you shouldn't update
>> whole oe-core as well.
>
> It seems like this part is already settled, but it would seem to me that
> this scenario, if I understand it correctly, is "I'm using oe-core and
> see up-stream meta-oe/meta-somethingorother has an updated or new recipe
> for something I want in my image but I don't want to do a pull on all of
> meta-oe and potentially cause a huge rebuild of stuff I don't really
> care about".
>
> That sounds like a problem better solved with 'git branch', 'git fetch'
> and 'git cherry-pick' on the developer's side than breaking up meta-oe
> across existing meta-boundaries.

Agreed. I was just probing to see if anyone had ideas on how that could
be managed by infrastructure, versus me mucking about.

Maybe RP's thoughts on layer tooling or setup possibilities would help,
but either way, I'll keep chugging along :D

Cheers,

Bruce

>
> -J.
>
>>
>> On Wed, Feb 21, 2018 at 1:51 AM, Bruce Ashfield 
>> wrote:
>>
>> > On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj  wrote:
>> > > On 2/20/18 9:13 AM, Bruce Ashfield wrote:
>> > >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 
>> > wrote:
>> > >>>
>> > >>>
>> > >>> On 02/20/2018 02:45 AM, Burton, Ross wrote:
>> >  Hi,
>> > 
>> >  Is now a good time to talk about splitting up meta-oe?  Some layers
>> > are
>> >  actively developed and maintained (one example: meta-python), others
>> > are
>> >  basically bitrotting and only get touched when something else causes
>> > them
>> >  to break world builds (one example: meta-gnome).  I've long felt that
>> >  meta-oe should be split up and the high quality layers managed in
>> > their own
>> >  repositories so patches to them don't get held up by breakage in other
>> >  sub-layers.
>> > >>> You make it sound like meta-oe is not a high quality layer.  I could
>> > >>> make the same claim about oe-core master.
>> > >>>
>> > >>> I don't see the connection in patches being held up due to breakage in
>> > >>> other sub layers. This only happens if the dependency fail to build.
>> > >>>
>> > >>> You lose control over the quality in current layers that reside in
>> > >>> meta-openbedded just like you have no control over all the other layers
>> > >>> residing in the community. It makes maintaining stable versions very
>> > >>> difficult. Well, unless The Yocto Project takes over them.. I guess
>> > that
>> > >>> would work then.
>> > >>>
>> > 
>> >  Another advantage of splitting out the high quality layers is that
>> > we'd
>> >  like to look at running more community layers through the Yocto
>> >  autobuilder, and granular layers make that easier to manage.
>> > >>>  I thought not including layers in bblayers.conf was easy enough.
>> > 
>> >  Comments?
>> > >>>
>> > >>> What problem do you thing you are trying to solve here?
>> > >>
>> > >> My unrelated issues are that I can't update one layer, without getting
>> > >> all of the updates.
>> > >> .. but that is both a good thing (i.e. they are all tested together,
>> > >> so you know that the
>> > >> single SRCREV update is good for all layers), and a bad thing (when
>> > >> you just want a
>> > >> new python recipe update from meta-python, but don't want other
>> > changes).
>> > >>
>> > >
>> > > if you dont include the layers in your BBLAYERS and they become
>> > > effectively non existent, unless you are on metered internet connection,
>> > > where downloading unused stuff would save you bandwidth, it should be
>> > > ok.  No ?
>> >
>> > Its not that.
>> >
>> > I *am* building the different layers, but say I have a stable set of
>> > packages
>> > and working images .. but for whatever reason, I need an updated
>> > python-
>> > package for an unrelated package, or some other layer that needs a newer
>> > version, etc.
>> >
>> > How do I get that, without taking updates to all the layers ? .. and
>> > layers that
>> > I really didn't want to update. I have to do some sort of combo-layer,
>> > carry
>> > my own copy of the recipe, etc.
>> >
>> > So there are definitely ways to do it, I'm just pointing out that I
>> > end up taking
>> > some build failures/issues from time to time on packages I didn't really
>> > need to update.
>> >
>> > The flip side of that argument is that all of the layers and sub layers
>> > have
>> > gone through some sort of global build, and hence I know that they all have
>> > worked together for someone. If I can update pieces 

Re: [oe] Splitting meta-oe?

[Joe MacDonald]

[Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 09:49) Martin Jansa wrote:

> > I need an updated python- package for an unrelated package
> 
> And how far will you go?
> 
> If you want just newer python- and nothing else, will you take other
> changes to other python-* recipes from meta-python layer? There is a lot of
> recipes there, if you're so picky about updates, then you shouldn't update
> whole oe-core as well.

It seems like this part is already settled, but it would seem to me that
this scenario, if I understand it correctly, is "I'm using oe-core and
see up-stream meta-oe/meta-somethingorother has an updated or new recipe
for something I want in my image but I don't want to do a pull on all of
meta-oe and potentially cause a huge rebuild of stuff I don't really
care about".

That sounds like a problem better solved with 'git branch', 'git fetch'
and 'git cherry-pick' on the developer's side than breaking up meta-oe
across existing meta-boundaries.

-J.

> 
> On Wed, Feb 21, 2018 at 1:51 AM, Bruce Ashfield 
> wrote:
> 
> > On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj  wrote:
> > > On 2/20/18 9:13 AM, Bruce Ashfield wrote:
> > >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 
> > wrote:
> > >>>
> > >>>
> > >>> On 02/20/2018 02:45 AM, Burton, Ross wrote:
> >  Hi,
> > 
> >  Is now a good time to talk about splitting up meta-oe?  Some layers
> > are
> >  actively developed and maintained (one example: meta-python), others
> > are
> >  basically bitrotting and only get touched when something else causes
> > them
> >  to break world builds (one example: meta-gnome).  I've long felt that
> >  meta-oe should be split up and the high quality layers managed in
> > their own
> >  repositories so patches to them don't get held up by breakage in other
> >  sub-layers.
> > >>> You make it sound like meta-oe is not a high quality layer.  I could
> > >>> make the same claim about oe-core master.
> > >>>
> > >>> I don't see the connection in patches being held up due to breakage in
> > >>> other sub layers. This only happens if the dependency fail to build.
> > >>>
> > >>> You lose control over the quality in current layers that reside in
> > >>> meta-openbedded just like you have no control over all the other layers
> > >>> residing in the community. It makes maintaining stable versions very
> > >>> difficult. Well, unless The Yocto Project takes over them.. I guess
> > that
> > >>> would work then.
> > >>>
> > 
> >  Another advantage of splitting out the high quality layers is that
> > we'd
> >  like to look at running more community layers through the Yocto
> >  autobuilder, and granular layers make that easier to manage.
> > >>>  I thought not including layers in bblayers.conf was easy enough.
> > 
> >  Comments?
> > >>>
> > >>> What problem do you thing you are trying to solve here?
> > >>
> > >> My unrelated issues are that I can't update one layer, without getting
> > >> all of the updates.
> > >> .. but that is both a good thing (i.e. they are all tested together,
> > >> so you know that the
> > >> single SRCREV update is good for all layers), and a bad thing (when
> > >> you just want a
> > >> new python recipe update from meta-python, but don't want other
> > changes).
> > >>
> > >
> > > if you dont include the layers in your BBLAYERS and they become
> > > effectively non existent, unless you are on metered internet connection,
> > > where downloading unused stuff would save you bandwidth, it should be
> > > ok.  No ?
> >
> > Its not that.
> >
> > I *am* building the different layers, but say I have a stable set of
> > packages
> > and working images .. but for whatever reason, I need an updated
> > python-
> > package for an unrelated package, or some other layer that needs a newer
> > version, etc.
> >
> > How do I get that, without taking updates to all the layers ? .. and
> > layers that
> > I really didn't want to update. I have to do some sort of combo-layer,
> > carry
> > my own copy of the recipe, etc.
> >
> > So there are definitely ways to do it, I'm just pointing out that I
> > end up taking
> > some build failures/issues from time to time on packages I didn't really
> > need to update.
> >
> > The flip side of that argument is that all of the layers and sub layers
> > have
> > gone through some sort of global build, and hence I know that they all have
> > worked together for someone. If I can update pieces individually, I break
> > that .. and I own the broken bits after that .. which again, goes to
> > my point that
> > fixing one workflow/issue can break another :D
> >
> > Bruce
> >
> > >
> > >> It is very likely that splitting the layer would help one issue, but
> > >> make the other worse.
> > >>
> > >> So no solution from me, just an observation about potential issue.
> > >>
> > >> Cheers,
> > >>
> > >> Bruce
> > >>
> > >>>
> > >>> - armin
> > 
> >  Ross
> 

Re: [oe] Splitting meta-oe?

[Bruce Ashfield]

On Wed, Feb 21, 2018 at 8:34 AM, Bruce Ashfield
 wrote:
> On Wed, Feb 21, 2018 at 3:49 AM, Martin Jansa  wrote:
>>> I need an updated python- package for an unrelated package
>>
>> And how far will you go?
>>
>
> pretty far. I work with a lot of deep stacks that have a lot of specific
> dependencies as well as compatibility issues.
>
>> If you want just newer python- and nothing else, will you take other
>> changes to other python-* recipes from meta-python layer? There is a lot of
>> recipes there, if you're so picky about updates, then you shouldn't update
>> whole oe-core as well.
>
> I actually don't always, but generally speaking, I haven't had many
> problems with package updates from oe-core. I end up with breakage
> due to core build system changes, and that impacts oe-core and any
> layer either.

oh, and I'd add that this point is somewhat contrived (few package
breakages), since that is really just a fallout of the oe-core packages
being fairly ... core .. (and boring), so really there aren't any hard or
strange dependencies that cause issues and that's a fall out of the
content, not the workflow or model (or git repo split, or not!).

Cheers,

Bruce

>
> But as I pointed out, I'm not looking to have my problem 'solved', I'm
> just pointing out that it is a valid concern .. whether or not others
> agree.
>
> Cheers,
>
> Bruce
>
>>
>> On Wed, Feb 21, 2018 at 1:51 AM, Bruce Ashfield 
>> wrote:
>>>
>>> On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj  wrote:
>>> > On 2/20/18 9:13 AM, Bruce Ashfield wrote:
>>> >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>> On 02/20/2018 02:45 AM, Burton, Ross wrote:
>>>  Hi,
>>> 
>>>  Is now a good time to talk about splitting up meta-oe?  Some layers
>>>  are
>>>  actively developed and maintained (one example: meta-python), others
>>>  are
>>>  basically bitrotting and only get touched when something else causes
>>>  them
>>>  to break world builds (one example: meta-gnome).  I've long felt that
>>>  meta-oe should be split up and the high quality layers managed in
>>>  their own
>>>  repositories so patches to them don't get held up by breakage in
>>>  other
>>>  sub-layers.
>>> >>> You make it sound like meta-oe is not a high quality layer.  I could
>>> >>> make the same claim about oe-core master.
>>> >>>
>>> >>> I don't see the connection in patches being held up due to breakage in
>>> >>> other sub layers. This only happens if the dependency fail to build.
>>> >>>
>>> >>> You lose control over the quality in current layers that reside in
>>> >>> meta-openbedded just like you have no control over all the other
>>> >>> layers
>>> >>> residing in the community. It makes maintaining stable versions very
>>> >>> difficult. Well, unless The Yocto Project takes over them.. I guess
>>> >>> that
>>> >>> would work then.
>>> >>>
>>> 
>>>  Another advantage of splitting out the high quality layers is that
>>>  we'd
>>>  like to look at running more community layers through the Yocto
>>>  autobuilder, and granular layers make that easier to manage.
>>> >>>  I thought not including layers in bblayers.conf was easy enough.
>>> 
>>>  Comments?
>>> >>>
>>> >>> What problem do you thing you are trying to solve here?
>>> >>
>>> >> My unrelated issues are that I can't update one layer, without getting
>>> >> all of the updates.
>>> >> .. but that is both a good thing (i.e. they are all tested together,
>>> >> so you know that the
>>> >> single SRCREV update is good for all layers), and a bad thing (when
>>> >> you just want a
>>> >> new python recipe update from meta-python, but don't want other
>>> >> changes).
>>> >>
>>> >
>>> > if you dont include the layers in your BBLAYERS and they become
>>> > effectively non existent, unless you are on metered internet connection,
>>> > where downloading unused stuff would save you bandwidth, it should be
>>> > ok.  No ?
>>>
>>> Its not that.
>>>
>>> I *am* building the different layers, but say I have a stable set of
>>> packages
>>> and working images .. but for whatever reason, I need an updated
>>> python-
>>> package for an unrelated package, or some other layer that needs a newer
>>> version, etc.
>>>
>>> How do I get that, without taking updates to all the layers ? .. and
>>> layers that
>>> I really didn't want to update. I have to do some sort of combo-layer,
>>> carry
>>> my own copy of the recipe, etc.
>>>
>>> So there are definitely ways to do it, I'm just pointing out that I
>>> end up taking
>>> some build failures/issues from time to time on packages I didn't really
>>> need to update.
>>>
>>> The flip side of that argument is that all of the layers and sub layers
>>> have
>>> gone through some sort of global build, and hence I know that they all
>>> have
>>> worked together for someone. If 

Re: [oe] Splitting meta-oe?

[Bruce Ashfield]

On Wed, Feb 21, 2018 at 3:49 AM, Martin Jansa  wrote:
>> I need an updated python- package for an unrelated package
>
> And how far will you go?
>

pretty far. I work with a lot of deep stacks that have a lot of specific
dependencies as well as compatibility issues.

> If you want just newer python- and nothing else, will you take other
> changes to other python-* recipes from meta-python layer? There is a lot of
> recipes there, if you're so picky about updates, then you shouldn't update
> whole oe-core as well.

I actually don't always, but generally speaking, I haven't had many
problems with package updates from oe-core. I end up with breakage
due to core build system changes, and that impacts oe-core and any
layer either.

But as I pointed out, I'm not looking to have my problem 'solved', I'm
just pointing out that it is a valid concern .. whether or not others
agree.

Cheers,

Bruce

>
> On Wed, Feb 21, 2018 at 1:51 AM, Bruce Ashfield 
> wrote:
>>
>> On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj  wrote:
>> > On 2/20/18 9:13 AM, Bruce Ashfield wrote:
>> >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 
>> >> wrote:
>> >>>
>> >>>
>> >>> On 02/20/2018 02:45 AM, Burton, Ross wrote:
>>  Hi,
>> 
>>  Is now a good time to talk about splitting up meta-oe?  Some layers
>>  are
>>  actively developed and maintained (one example: meta-python), others
>>  are
>>  basically bitrotting and only get touched when something else causes
>>  them
>>  to break world builds (one example: meta-gnome).  I've long felt that
>>  meta-oe should be split up and the high quality layers managed in
>>  their own
>>  repositories so patches to them don't get held up by breakage in
>>  other
>>  sub-layers.
>> >>> You make it sound like meta-oe is not a high quality layer.  I could
>> >>> make the same claim about oe-core master.
>> >>>
>> >>> I don't see the connection in patches being held up due to breakage in
>> >>> other sub layers. This only happens if the dependency fail to build.
>> >>>
>> >>> You lose control over the quality in current layers that reside in
>> >>> meta-openbedded just like you have no control over all the other
>> >>> layers
>> >>> residing in the community. It makes maintaining stable versions very
>> >>> difficult. Well, unless The Yocto Project takes over them.. I guess
>> >>> that
>> >>> would work then.
>> >>>
>> 
>>  Another advantage of splitting out the high quality layers is that
>>  we'd
>>  like to look at running more community layers through the Yocto
>>  autobuilder, and granular layers make that easier to manage.
>> >>>  I thought not including layers in bblayers.conf was easy enough.
>> 
>>  Comments?
>> >>>
>> >>> What problem do you thing you are trying to solve here?
>> >>
>> >> My unrelated issues are that I can't update one layer, without getting
>> >> all of the updates.
>> >> .. but that is both a good thing (i.e. they are all tested together,
>> >> so you know that the
>> >> single SRCREV update is good for all layers), and a bad thing (when
>> >> you just want a
>> >> new python recipe update from meta-python, but don't want other
>> >> changes).
>> >>
>> >
>> > if you dont include the layers in your BBLAYERS and they become
>> > effectively non existent, unless you are on metered internet connection,
>> > where downloading unused stuff would save you bandwidth, it should be
>> > ok.  No ?
>>
>> Its not that.
>>
>> I *am* building the different layers, but say I have a stable set of
>> packages
>> and working images .. but for whatever reason, I need an updated
>> python-
>> package for an unrelated package, or some other layer that needs a newer
>> version, etc.
>>
>> How do I get that, without taking updates to all the layers ? .. and
>> layers that
>> I really didn't want to update. I have to do some sort of combo-layer,
>> carry
>> my own copy of the recipe, etc.
>>
>> So there are definitely ways to do it, I'm just pointing out that I
>> end up taking
>> some build failures/issues from time to time on packages I didn't really
>> need to update.
>>
>> The flip side of that argument is that all of the layers and sub layers
>> have
>> gone through some sort of global build, and hence I know that they all
>> have
>> worked together for someone. If I can update pieces individually, I break
>> that .. and I own the broken bits after that .. which again, goes to
>> my point that
>> fixing one workflow/issue can break another :D
>>
>> Bruce
>>
>> >
>> >> It is very likely that splitting the layer would help one issue, but
>> >> make the other worse.
>> >>
>> >> So no solution from me, just an observation about potential issue.
>> >>
>> >> Cheers,
>> >>
>> >> Bruce
>> >>
>> >>>
>> >>> - armin
>> 
>>  Ross
>> >>>
>> >>>
>> >>> --
>> >>> ___
>> >>> Openembedded-devel 

Re: [oe] [meta-qt4] Cmake Could NOT find Qt4, missing: QT_MOC_EXECUTABLE

[Måns Zigher]

When running devshell I can verify that echo $PATH includes the
recipe-sysroot-native dir and if I run "whereis qmake2" the
recipe-sysroot-native dir appears. So the question remains why is CMake not
detecting the binaries?

BR
Mans Zigher

2018-02-21 13:02 GMT+01:00 Måns Zigher :

> Hi,
>
> I am trying to build a native QT application that is required when
> generating the image. The recipe is depending on qt4-native and i am using
> poky version rocko. The application is using CMake which is producing the
> following error
>
> | -- Looking for Q_WS_MAC - not found
> | CMake Error at recipe-sysroot-native/usr/shar
> e/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
>
> |   Could NOT find Qt4 (missing: QT_MOC_EXECUTABLE QT_RCC_EXECUTABLE
> |   QT_UIC_EXECUTABLE) (found version "4.8.7")
> | Call Stack (most recent call first):
> |   
> recipe-sysroot-native/usr/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377
> (_FPHSA_FAILURE_MESSAGE)
> |   recipe-sysroot-native/usr/share/cmake-3.8/Modules/FindQt4.cmake:1326
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
> |   CMakeLists.txt:5 (find_package)
>
> When using jethro the recipe works fine. If I search for qmake2 in the
> build directory we get the following hits
>
> ./tmp/sysroots-components/x86_64/qt4-native/usr/bin/qmake2
> ./tmp/work/x86_64-linux/my-qt-application/0.1-r0/recipe-sysr
> oot-native/usr/bin/qmake2
> ./tmp/work/x86_64-linux/qt4-native/4.8.7-r0/sysroot-destdir/
> home/build/tmp/work/x86_64-linux/qt4-native/4.8.7-r0/
> recipe-sysroot-native/usr/bin/qmake2
>
> I would think that CMake should find qmake2 in the recipe-sysroot-native
> dir. Any help would be appreciated. How can I point CMake in the direction
> so it finds the qt tools.
>
> BR
> Måns Zigher
>
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-qt4] Cmake Could NOT find Qt4, missing: QT_MOC_EXECUTABLE

[Måns Zigher]

Hi,

I am trying to build a native QT application that is required when
generating the image. The recipe is depending on qt4-native and i am using
poky version rocko. The application is using CMake which is producing the
following error

| -- Looking for Q_WS_MAC - not found
| CMake Error at recipe-sysroot-native/usr/share/cmake-3.8/Modules/
FindPackageHandleStandardArgs.cmake:137 (message):
|   Could NOT find Qt4 (missing: QT_MOC_EXECUTABLE QT_RCC_EXECUTABLE
|   QT_UIC_EXECUTABLE) (found version "4.8.7")
| Call Stack (most recent call first):
|   recipe-sysroot-native/usr/share/cmake-3.8/Modules/
FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE)

|   recipe-sysroot-native/usr/share/cmake-3.8/Modules/FindQt4.cmake:1326
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
|   CMakeLists.txt:5 (find_package)

When using jethro the recipe works fine. If I search for qmake2 in the
build directory we get the following hits

./tmp/sysroots-components/x86_64/qt4-native/usr/bin/qmake2
./tmp/work/x86_64-linux/my-qt-application/0.1-r0/recipe-
sysroot-native/usr/bin/qmake2
./tmp/work/x86_64-linux/qt4-native/4.8.7-r0/sysroot-
destdir/home/build/tmp/work/x86_64-linux/qt4-native/4.8.7-
r0/recipe-sysroot-native/usr/bin/qmake2

I would think that CMake should find qmake2 in the recipe-sysroot-native
dir. Any help would be appreciated. How can I point CMake in the direction
so it finds the qt tools.

BR
Måns Zigher
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe?

[Martin Jansa]

There is good example of inter-layer dependencies from real world:
http://lists.openembedded.org/pipermail/openembedded-devel/2017-February/111447.html

Do you want
A) new git repository meta-libio-socket-ssl-perl so that meta-networking
will depend on this on instead of whole meta-perl
B) meta-ddclient which will probably depend on both meta-perl and
meta-networking
C) ddclient and its dependencies in meta-perl
D) libio-socket-ssl-perl moved to oe-core, so that next time we can say
that oe-core is just like old oe-classic just with a bit less stuff in it

Neither of these options is ideal, but meta-networking getting meta-perl
dependency is the one which causes fewest issues to OE users. As mentioned
before by few people, most builds for "real world products" are already
including many layers, adding meta-perl to BBLAYERS (it's probably there
already for other recipes) without the need to update other build setup
like checking additional git repositories is simple and I don't see how it
makes meta-oe to be like oe-classic. The layers still separate stuff and I
don't need to include layers from where I don't need anything at all.

Smallest set of upstream layers we use at LGE already contains half of
meta-oe repository:
oe-core meta-gplv2 meta-oe meta-multimedia meta-networking meta-python
meta-filesystems meta-qt5
and around 8 internal layers, so it's far from oe-classic days and
different builds for different products have different subset of layers.

For internal layers we also use only a few git repositories 12 layers in
the main one, because it makes it easier to keep them all compatible with
each other at all times (e.g. by triggering the CI for all products from
each gerrit review for this single repository).

I'm not advocating for putting _everything_ into single git repository or
even the use of combo-layer tool, but keeping the layers maintained by the
same "organization" with the same update cycle makes things easier to
maintain and easier to consume by others.

Regards,

On Wed, Feb 21, 2018 at 10:48 AM, Andrea Adami 
wrote:

> On Wed, Feb 21, 2018 at 10:06 AM, Martin Jansa 
> wrote:
> >> I'm actually very worried about these (re)tired maintainers. If the
> > layers were more independent it would allow some of the patch handling
> > responsibilities and testing responsibilities to move to other people,
> > reducing the load on those maintainers.
> >
> > Armin can update his own view, but for me the main issue wasn't the
> "patch
> > handling" part, but actually the lack of patches for the new issues
> (often
> > caused by new changes in oe-core).
> >
>
> That's one point.
> If I may add my experience as maintainer of two minor layers
> (meta-handheld and meta-initramfs), I have to say there have been many
> cases where an upgrade to oe-core did break one of these layers.
> Just a variable rename for example...this fall-outs could have been
> avoided if the oe-core dev would have spent a minute grepping the
> repository,
> Heh..now we have to define what is the public repository, which layers
> have to be checked...
>
> And about layer interdependencies...well..it is very delicate.
> For example meta-handheld, a BSP layer, must depend since some time on
> meta-oe. Why? Because tslib was removed from oe-core.
> This is ugly...here a more separated layering structure would help
>
> So I somehow feel we should refine what is in the repository but
> absolutely not split it around.
> Even, I think we should host all public layers (definition lacks
> today) in the OpenEmbedded Git Repository .
>
> My 2 cents
> Andrea
>
> > Yes, the "patch handling" part was the most boring piece, but patches
> from
> > regular contributors or co-maintainers were always easy to handle and
> > rarely caused any extra work.
> >
> > The untested drive-by contributions from people who don't even reply to
> > review comments are completely different category, but separate git
> > repositories won't drive those away (until it gets so confusing that
> these
> > people will even fail to find correct repository and just gave up trying
> to
> > contribute anything at all). Nothing is blocking more people to collect,
> > fix, test these drive-by contributions and then send consolidated
> > pull-request which will be easily merged to shared repository - but I
> never
> > seen this happen and I don't know how separate git repositories will help
> > with this.
> >
> > In the end after spending a lot of own time doing this boring part, I
> > always felt responsible for fixing as many build failures detected in
> world
> > build as I could, but that's never-ending uphill battle where very few
> > people ever help (big thanks to those exceptions who sometimes help). And
> > what you get for that extra afford to get it building as much as possible
> > in spare time? Comments about how garbage meta-oe layers are.
> >
> > We need patches not more git repos!
> >
> > On Wed, Feb 21, 2018 at 

Re: [oe] Splitting meta-oe?

[Andrea Adami]

On Wed, Feb 21, 2018 at 10:06 AM, Martin Jansa  wrote:
>> I'm actually very worried about these (re)tired maintainers. If the
> layers were more independent it would allow some of the patch handling
> responsibilities and testing responsibilities to move to other people,
> reducing the load on those maintainers.
>
> Armin can update his own view, but for me the main issue wasn't the "patch
> handling" part, but actually the lack of patches for the new issues (often
> caused by new changes in oe-core).
>

That's one point.
If I may add my experience as maintainer of two minor layers
(meta-handheld and meta-initramfs), I have to say there have been many
cases where an upgrade to oe-core did break one of these layers.
Just a variable rename for example...this fall-outs could have been
avoided if the oe-core dev would have spent a minute grepping the
repository,
Heh..now we have to define what is the public repository, which layers
have to be checked...

And about layer interdependencies...well..it is very delicate.
For example meta-handheld, a BSP layer, must depend since some time on
meta-oe. Why? Because tslib was removed from oe-core.
This is ugly...here a more separated layering structure would help

So I somehow feel we should refine what is in the repository but
absolutely not split it around.
Even, I think we should host all public layers (definition lacks
today) in the OpenEmbedded Git Repository .

My 2 cents
Andrea

> Yes, the "patch handling" part was the most boring piece, but patches from
> regular contributors or co-maintainers were always easy to handle and
> rarely caused any extra work.
>
> The untested drive-by contributions from people who don't even reply to
> review comments are completely different category, but separate git
> repositories won't drive those away (until it gets so confusing that these
> people will even fail to find correct repository and just gave up trying to
> contribute anything at all). Nothing is blocking more people to collect,
> fix, test these drive-by contributions and then send consolidated
> pull-request which will be easily merged to shared repository - but I never
> seen this happen and I don't know how separate git repositories will help
> with this.
>
> In the end after spending a lot of own time doing this boring part, I
> always felt responsible for fixing as many build failures detected in world
> build as I could, but that's never-ending uphill battle where very few
> people ever help (big thanks to those exceptions who sometimes help). And
> what you get for that extra afford to get it building as much as possible
> in spare time? Comments about how garbage meta-oe layers are.
>
> We need patches not more git repos!
>
> On Wed, Feb 21, 2018 at 9:49 AM, Martin Jansa 
> wrote:
>
>> > I need an updated python- package for an unrelated package
>>
>> And how far will you go?
>>
>> If you want just newer python- and nothing else, will you take other
>> changes to other python-* recipes from meta-python layer? There is a lot of
>> recipes there, if you're so picky about updates, then you shouldn't update
>> whole oe-core as well.
>>
>> On Wed, Feb 21, 2018 at 1:51 AM, Bruce Ashfield 
>> wrote:
>>
>>> On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj  wrote:
>>> > On 2/20/18 9:13 AM, Bruce Ashfield wrote:
>>> >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 
>>> wrote:
>>> >>>
>>> >>>
>>> >>> On 02/20/2018 02:45 AM, Burton, Ross wrote:
>>>  Hi,
>>> 
>>>  Is now a good time to talk about splitting up meta-oe?  Some layers
>>> are
>>>  actively developed and maintained (one example: meta-python), others
>>> are
>>>  basically bitrotting and only get touched when something else causes
>>> them
>>>  to break world builds (one example: meta-gnome).  I've long felt that
>>>  meta-oe should be split up and the high quality layers managed in
>>> their own
>>>  repositories so patches to them don't get held up by breakage in
>>> other
>>>  sub-layers.
>>> >>> You make it sound like meta-oe is not a high quality layer.  I could
>>> >>> make the same claim about oe-core master.
>>> >>>
>>> >>> I don't see the connection in patches being held up due to breakage in
>>> >>> other sub layers. This only happens if the dependency fail to build.
>>> >>>
>>> >>> You lose control over the quality in current layers that reside in
>>> >>> meta-openbedded just like you have no control over all the other
>>> layers
>>> >>> residing in the community. It makes maintaining stable versions very
>>> >>> difficult. Well, unless The Yocto Project takes over them.. I guess
>>> that
>>> >>> would work then.
>>> >>>
>>> 
>>>  Another advantage of splitting out the high quality layers is that
>>> we'd
>>>  like to look at running more community layers through the Yocto
>>>  autobuilder, and granular layers make that easier to manage.

Re: [oe] Splitting meta-oe?

[Martin Jansa]

> I'm actually very worried about these (re)tired maintainers. If the
layers were more independent it would allow some of the patch handling
responsibilities and testing responsibilities to move to other people,
reducing the load on those maintainers.

Armin can update his own view, but for me the main issue wasn't the "patch
handling" part, but actually the lack of patches for the new issues (often
caused by new changes in oe-core).

Yes, the "patch handling" part was the most boring piece, but patches from
regular contributors or co-maintainers were always easy to handle and
rarely caused any extra work.

The untested drive-by contributions from people who don't even reply to
review comments are completely different category, but separate git
repositories won't drive those away (until it gets so confusing that these
people will even fail to find correct repository and just gave up trying to
contribute anything at all). Nothing is blocking more people to collect,
fix, test these drive-by contributions and then send consolidated
pull-request which will be easily merged to shared repository - but I never
seen this happen and I don't know how separate git repositories will help
with this.

In the end after spending a lot of own time doing this boring part, I
always felt responsible for fixing as many build failures detected in world
build as I could, but that's never-ending uphill battle where very few
people ever help (big thanks to those exceptions who sometimes help). And
what you get for that extra afford to get it building as much as possible
in spare time? Comments about how garbage meta-oe layers are.

We need patches not more git repos!

On Wed, Feb 21, 2018 at 9:49 AM, Martin Jansa 
wrote:

> > I need an updated python- package for an unrelated package
>
> And how far will you go?
>
> If you want just newer python- and nothing else, will you take other
> changes to other python-* recipes from meta-python layer? There is a lot of
> recipes there, if you're so picky about updates, then you shouldn't update
> whole oe-core as well.
>
> On Wed, Feb 21, 2018 at 1:51 AM, Bruce Ashfield 
> wrote:
>
>> On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj  wrote:
>> > On 2/20/18 9:13 AM, Bruce Ashfield wrote:
>> >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 
>> wrote:
>> >>>
>> >>>
>> >>> On 02/20/2018 02:45 AM, Burton, Ross wrote:
>>  Hi,
>> 
>>  Is now a good time to talk about splitting up meta-oe?  Some layers
>> are
>>  actively developed and maintained (one example: meta-python), others
>> are
>>  basically bitrotting and only get touched when something else causes
>> them
>>  to break world builds (one example: meta-gnome).  I've long felt that
>>  meta-oe should be split up and the high quality layers managed in
>> their own
>>  repositories so patches to them don't get held up by breakage in
>> other
>>  sub-layers.
>> >>> You make it sound like meta-oe is not a high quality layer.  I could
>> >>> make the same claim about oe-core master.
>> >>>
>> >>> I don't see the connection in patches being held up due to breakage in
>> >>> other sub layers. This only happens if the dependency fail to build.
>> >>>
>> >>> You lose control over the quality in current layers that reside in
>> >>> meta-openbedded just like you have no control over all the other
>> layers
>> >>> residing in the community. It makes maintaining stable versions very
>> >>> difficult. Well, unless The Yocto Project takes over them.. I guess
>> that
>> >>> would work then.
>> >>>
>> 
>>  Another advantage of splitting out the high quality layers is that
>> we'd
>>  like to look at running more community layers through the Yocto
>>  autobuilder, and granular layers make that easier to manage.
>> >>>  I thought not including layers in bblayers.conf was easy enough.
>> 
>>  Comments?
>> >>>
>> >>> What problem do you thing you are trying to solve here?
>> >>
>> >> My unrelated issues are that I can't update one layer, without getting
>> >> all of the updates.
>> >> .. but that is both a good thing (i.e. they are all tested together,
>> >> so you know that the
>> >> single SRCREV update is good for all layers), and a bad thing (when
>> >> you just want a
>> >> new python recipe update from meta-python, but don't want other
>> changes).
>> >>
>> >
>> > if you dont include the layers in your BBLAYERS and they become
>> > effectively non existent, unless you are on metered internet connection,
>> > where downloading unused stuff would save you bandwidth, it should be
>> > ok.  No ?
>>
>> Its not that.
>>
>> I *am* building the different layers, but say I have a stable set of
>> packages
>> and working images .. but for whatever reason, I need an updated
>> python-
>> package for an unrelated package, or some other layer that needs a newer
>> version, etc.
>>
>> How do I get that, without taking updates 

Re: [oe] Splitting meta-oe?

[Martin Jansa]

> I need an updated python- package for an unrelated package

And how far will you go?

If you want just newer python- and nothing else, will you take other
changes to other python-* recipes from meta-python layer? There is a lot of
recipes there, if you're so picky about updates, then you shouldn't update
whole oe-core as well.

On Wed, Feb 21, 2018 at 1:51 AM, Bruce Ashfield 
wrote:

> On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj  wrote:
> > On 2/20/18 9:13 AM, Bruce Ashfield wrote:
> >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 
> wrote:
> >>>
> >>>
> >>> On 02/20/2018 02:45 AM, Burton, Ross wrote:
>  Hi,
> 
>  Is now a good time to talk about splitting up meta-oe?  Some layers
> are
>  actively developed and maintained (one example: meta-python), others
> are
>  basically bitrotting and only get touched when something else causes
> them
>  to break world builds (one example: meta-gnome).  I've long felt that
>  meta-oe should be split up and the high quality layers managed in
> their own
>  repositories so patches to them don't get held up by breakage in other
>  sub-layers.
> >>> You make it sound like meta-oe is not a high quality layer.  I could
> >>> make the same claim about oe-core master.
> >>>
> >>> I don't see the connection in patches being held up due to breakage in
> >>> other sub layers. This only happens if the dependency fail to build.
> >>>
> >>> You lose control over the quality in current layers that reside in
> >>> meta-openbedded just like you have no control over all the other layers
> >>> residing in the community. It makes maintaining stable versions very
> >>> difficult. Well, unless The Yocto Project takes over them.. I guess
> that
> >>> would work then.
> >>>
> 
>  Another advantage of splitting out the high quality layers is that
> we'd
>  like to look at running more community layers through the Yocto
>  autobuilder, and granular layers make that easier to manage.
> >>>  I thought not including layers in bblayers.conf was easy enough.
> 
>  Comments?
> >>>
> >>> What problem do you thing you are trying to solve here?
> >>
> >> My unrelated issues are that I can't update one layer, without getting
> >> all of the updates.
> >> .. but that is both a good thing (i.e. they are all tested together,
> >> so you know that the
> >> single SRCREV update is good for all layers), and a bad thing (when
> >> you just want a
> >> new python recipe update from meta-python, but don't want other
> changes).
> >>
> >
> > if you dont include the layers in your BBLAYERS and they become
> > effectively non existent, unless you are on metered internet connection,
> > where downloading unused stuff would save you bandwidth, it should be
> > ok.  No ?
>
> Its not that.
>
> I *am* building the different layers, but say I have a stable set of
> packages
> and working images .. but for whatever reason, I need an updated
> python-
> package for an unrelated package, or some other layer that needs a newer
> version, etc.
>
> How do I get that, without taking updates to all the layers ? .. and
> layers that
> I really didn't want to update. I have to do some sort of combo-layer,
> carry
> my own copy of the recipe, etc.
>
> So there are definitely ways to do it, I'm just pointing out that I
> end up taking
> some build failures/issues from time to time on packages I didn't really
> need to update.
>
> The flip side of that argument is that all of the layers and sub layers
> have
> gone through some sort of global build, and hence I know that they all have
> worked together for someone. If I can update pieces individually, I break
> that .. and I own the broken bits after that .. which again, goes to
> my point that
> fixing one workflow/issue can break another :D
>
> Bruce
>
> >
> >> It is very likely that splitting the layer would help one issue, but
> >> make the other worse.
> >>
> >> So no solution from me, just an observation about potential issue.
> >>
> >> Cheers,
> >>
> >> Bruce
> >>
> >>>
> >>> - armin
> 
>  Ross
> >>>
> >>>
> >>> --
> >>> ___
> >>> Openembedded-devel mailing list
> >>> Openembedded-devel@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >>
> >>
> >>
> >
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel