Re: [oe] [meta-qt5][PATCHv2] qt5-git.inc: drop nobranch=1

[Samuli Piippo]

What I don't understand is that why are we checking if SRCREV is found
from the branch.
Full git repo is always fetched and if the SHA1 is valid, it will be
found, regardless of from which branch it is accessible at the time.

On 22 February 2018 at 19:59, Martin Jansa  wrote:
> Why do they disappear? Or why aren't they included in 5.x branches at the
> time of the release so that we can use just 5.x without the SRCREVs being
> only on 5.x.x branches?
>
> On Thu, Feb 22, 2018 at 6:27 PM, Samuli Piippo 
> wrote:
>>
>> Note that the Qt release branches (5.x.x) will usually disappear right
>> after the release, which will break the build without nobranch=1
>>
>> On 22 February 2018 at 19:02, Martin Jansa  wrote:
>> > * sneaked in with:
>> >   commit 333949a8239dfa7788b35f1059614733e11a6a25
>> >   Author: Samuli Piippo 
>> >   Date:   Thu Jan 26 16:54:50 2017 +0200
>> >
>> > Upgrade to Qt 5.8
>> > * use 5.10.1 branch by defaut and fix QT_MODULE_BRANCH
>> >   in qtknx, qtmqtt, qtwebkit-examples, qtwebkit which don't
>> >   have 5.10.1 branch at all
>> >
>> > Signed-off-by: Martin Jansa 
>> > ---
>> >  recipes-qt/qt5/qt5-git.inc  | 6 +++---
>> >  recipes-qt/qt5/qtknx_git.bb | 2 ++
>> >  recipes-qt/qt5/qtmqtt_git.bb| 2 ++
>> >  recipes-qt/qt5/qtwebkit-examples_git.bb | 2 ++
>> >  recipes-qt/qt5/qtwebkit_git.bb  | 2 ++
>> >  5 files changed, 11 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/recipes-qt/qt5/qt5-git.inc b/recipes-qt/qt5/qt5-git.inc
>> > index 7ee0643..beba913 100644
>> > --- a/recipes-qt/qt5/qt5-git.inc
>> > +++ b/recipes-qt/qt5/qt5-git.inc
>> > @@ -1,9 +1,9 @@
>> >  # Copyright (C) 2012-2016 O.S. Systems Software LTDA.
>> > -# Copyright (C) 2013-2017 Martin Jansa 
>> > +# Copyright (C) 2013-2018 Martin Jansa 
>> >
>> >  QT_MODULE ?= "${BPN}"
>> > -QT_MODULE_BRANCH ?= "5.10"
>> > -QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH};nobranch=1"
>> > +QT_MODULE_BRANCH ?= "5.10.1"
>> > +QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH}"
>> >
>> >  # each module needs to define valid SRCREV
>> >  SRC_URI = " \
>> > diff --git a/recipes-qt/qt5/qtknx_git.bb b/recipes-qt/qt5/qtknx_git.bb
>> > index 5e01e3c..fa981ab 100644
>> > --- a/recipes-qt/qt5/qtknx_git.bb
>> > +++ b/recipes-qt/qt5/qtknx_git.bb
>> > @@ -9,4 +9,6 @@ LIC_FILES_CHKSUM = " \
>> >
>> >  DEPENDS += "qtbase"
>> >
>> > +QT_MODULE_BRANCH = "5.10"
>> > +
>> >  SRCREV = "29c34e8f072afd01002ed3847d752b4e065f977e"
>> > diff --git a/recipes-qt/qt5/qtmqtt_git.bb b/recipes-qt/qt5/qtmqtt_git.bb
>> > index b705f7c..90c255d 100644
>> > --- a/recipes-qt/qt5/qtmqtt_git.bb
>> > +++ b/recipes-qt/qt5/qtmqtt_git.bb
>> > @@ -9,4 +9,6 @@ LIC_FILES_CHKSUM = " \
>> >
>> >  DEPENDS += "qtbase"
>> >
>> > +QT_MODULE_BRANCH = "5.10"
>> > +
>> >  SRCREV = "2c3c2a41c55a179332ec2a076856990f36dd5ef9"
>> > diff --git a/recipes-qt/qt5/qtwebkit-examples_git.bb
>> > b/recipes-qt/qt5/qtwebkit-examples_git.bb
>> > index 3e3e4a0..114fab7 100644
>> > --- a/recipes-qt/qt5/qtwebkit-examples_git.bb
>> > +++ b/recipes-qt/qt5/qtwebkit-examples_git.bb
>> > @@ -17,4 +17,6 @@ DEPENDS += "qtwebkit qtxmlpatterns"
>> >  RDEPENDS_${PN}-examples += "qtwebkit-qmlplugins"
>> >  RDEPENDS_${PN}-examples +=
>> > "${@bb.utils.contains('PACKAGECONFIG_OPENSSL', 'openssl', 
>> > 'ca-certificates',
>> > '', d)}"
>> >
>> > +QT_MODULE_BRANCH = "5.9"
>> > +
>> >  SRCREV = "a24c780b60d7d8bc00c4a48042cf7f32db777d55"
>> > diff --git a/recipes-qt/qt5/qtwebkit_git.bb
>> > b/recipes-qt/qt5/qtwebkit_git.bb
>> > index 5dee6a4..b23d4d6 100644
>> > --- a/recipes-qt/qt5/qtwebkit_git.bb
>> > +++ b/recipes-qt/qt5/qtwebkit_git.bb
>> > @@ -87,4 +87,6 @@ PACKAGES_remove = "${PN}-examples-dev
>> > ${PN}-examples-staticdev ${PN}-examples-db
>> >  RUBY_SYS = "${@ '${BUILD_SYS}'.replace('i486', 'i386').replace('i586',
>> > 'i386').replace('i686', 'i386') }"
>> >  export
>> > RUBYLIB="${STAGING_DATADIR_NATIVE}/rubygems:${STAGING_LIBDIR_NATIVE}/ruby:${STAGING_LIBDIR_NATIVE}/ruby/${RUBY_SYS}"
>> >
>> > +QT_MODULE_BRANCH = "5.9"
>> > +
>> >  SRCREV = "97c4a80a1282c8c3eaa343011286b76fd4838c5f"
>> > --
>> > 2.15.1
>> >
>> > --
>> > ___
>> > 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

[oe] [meta-oe][PATCH] nodejs_8.9.0: add RDEPENDS for building

[Trevor Woerner]

If you want to perform an "npm install" and a module needs to be compiled,
these additional packages need to be installed otherwise the following import
errors may occur:

ImportError: No module named compiler.ast
ImportError: No module named filecmp
ImportError: No module named multiprocessing

Signed-off-by: Trevor Woerner 
---
 meta-oe/recipes-devtools/nodejs/nodejs_8.9.0.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta-oe/recipes-devtools/nodejs/nodejs_8.9.0.bb 
b/meta-oe/recipes-devtools/nodejs/nodejs_8.9.0.bb
index 1cab6a4978..a4e50f142f 100644
--- a/meta-oe/recipes-devtools/nodejs/nodejs_8.9.0.bb
+++ b/meta-oe/recipes-devtools/nodejs/nodejs_8.9.0.bb
@@ -80,7 +80,8 @@ do_install_append_class-target() {
 
 PACKAGES =+ "${PN}-npm"
 FILES_${PN}-npm = "${exec_prefix}/lib/node_modules ${bindir}/npm ${bindir}/npx"
-RDEPENDS_${PN}-npm = "bash python-shell python-datetime python-subprocess 
python-textutils"
+RDEPENDS_${PN}-npm = "bash python-shell python-datetime python-subprocess 
python-textutils \
+python-compiler python-misc python-multiprocessing"
 
 PACKAGES =+ "${PN}-systemtap"
 FILES_${PN}-systemtap = "${datadir}/systemtap"
-- 
2.14.1.459.g238e487ea

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

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

[Khem Raj]

On Thu, Feb 22, 2018 at 5:27 PM, Martin Jansa  wrote:
> On Wed, Feb 21, 2018 at 08:29:40PM -0800, Khem Raj wrote:
>> 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"
>
> Should renameat2 be enabled by default?
>
> Either the test for it is broken in 5.11 or it's not available in
> default setup.
>

Its ok to keep them enabled by default. but I think this is a bug that
should be reported
to upstream QT, if the feature is knobbale then it should have worked.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Martin Jansa]

On Wed, Feb 21, 2018 at 08:29:40PM -0800, Khem Raj wrote:
> 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"

Should renameat2 be enabled by default?

Either the test for it is broken in 5.11 or it's not available in
default setup.

In 2 very different builds it currently fail for me with:
| ERROR: Feature 'renameat2' was enabled, but the pre-condition 'config.linux 
&& tests.renameat2' failed.

| Checking for renameat2()...
| + cd 
/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/build/config.tests/renameat2
 && 
PKG_CONFIG_SYSROOT_DIR=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot
 
PKG_CONFIG_LIBDIR=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot/usr/lib/pkgconfig
 
/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot-native/usr/bin/qt5/qmake
 -qtconf 
/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/build/bin/qt.conf
 "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared 
use_gold_linker warn_off console single_arch" "QMAKE_CFLAGS += 
--sysroot=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot"
 "QMAKE_CXXFLAGS += 
--sysroot=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot"
 "QMAKE_LFLAGS += 
--sysroot=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot"
 -early "CONFIG += cross_compile" 
/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/build/config.tests/renameat2
| + cd 
/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/build/config.tests/renameat2
 && MAKEFLAGS= make
| > aarch64-webos-linux-g++  
--sysroot=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot
 -c -pipe  -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0=/usr/src/debug/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0
 
-fdebug-prefix-map=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot-native=
 
-fdebug-prefix-map=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot=
  -fvisibility-inlines-hidden 
--sysroot=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot
 
--sysroot=/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/recipe-sysroot
 -O2 -w -fPIC  -I. 
-I/OE/build/owpb/webos-ports/tmp-glibc/work/aarch64-webos-linux/qtbase/5.10.1+5.11-alpha+gitAUTOINC+17b73b0d2b-r0/git/mkspecs/linux-oe-g++
 -o main.o main.cpp
| > main.cpp: In function 'int main(int, char**)':
| > main.cpp:9:53: error: 'RENAME_NOREPLACE' was not declared in this scope
| >  renameat2(AT_FDCWD, argv[1], AT_FDCWD, argv[2], RENAME_NOREPLACE | 
RENAME_WHITEOUT);
| >  ^~~~
| > main.cpp:9:53: note: suggested alternative: '_IOS_NOREPLACE'
| >  renameat2(AT_FDCWD, argv[1], AT_FDCWD, argv[2], RENAME_NOREPLACE | 
RENAME_WHITEOUT);
| >  ^~~~
| >  _IOS_NOREPLACE
| > main.cpp:9:72: error: 'RENAME_WHITEOUT' was not declared in this scope
| >  renameat2(AT_FDCWD, argv[1], AT_FDCWD, argv[2], RENAME_NOREPLACE | 
RENAME_WHITEOUT);
| >  

Re: [oe] [OE-core] [RFC] Rename meta-openembedded to openembedded-extras

[akuster808]

On 02/21/2018 11:55 PM, Andrea Adami wrote:
> All,
> it seems there is some consensus about reordering/cleaning the
> "OpenEmbedded layers".
>
> I think that before starting any cleaning *inside* we should finally
> clean up the confusion about meta-oe meta-openembedded
> openembedded-layers, etc..
>
> I think it would be advisable to rename the repository from
> meta-openembedded to openembedded-extras, matching the
> openembedded-core naming schema.
Renaming an existing repo will cause more damage than what benefit one
thinks it may solve. 

I think openembededd-core is incorrect. it should have been
meta-openbedded-core or meta-core.

- armin
>
> Regards
> Andrea
>
>
> P.S.
> One layer of this repo would be the (in)famous meta-oe.
> I can't imagine right now a definition for it: it contains old
> versions of oe-core recipes, expunged recipes, tools and libraries
> needed by other layers (i.e. tslib), etc. etc.
> This one will need a separate thread.


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

[oe] [meta-qt5][pyro][PATCH] qt5-git.inc: drop nobranch=1

[Martin Jansa]

* sneaked in with:
  commit 333949a8239dfa7788b35f1059614733e11a6a25
  Author: Samuli Piippo 
  Date:   Thu Jan 26 16:54:50 2017 +0200

Upgrade to Qt 5.8

Signed-off-by: Martin Jansa 
---
 recipes-qt/qt5/qt5-git.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-qt/qt5/qt5-git.inc b/recipes-qt/qt5/qt5-git.inc
index f864953..a1dd16a 100644
--- a/recipes-qt/qt5/qt5-git.inc
+++ b/recipes-qt/qt5/qt5-git.inc
@@ -3,7 +3,7 @@
 
 QT_MODULE ?= "${BPN}"
 QT_MODULE_BRANCH ?= "5.8"
-QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH};nobranch=1"
+QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH}"
 
 # each module needs to define valid SRCREV
 SRC_URI = " \
-- 
2.15.1

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

Re: [oe] [meta-qt5][PATCHv2] qt5-git.inc: drop nobranch=1

[Martin Jansa]

Why do they disappear? Or why aren't they included in 5.x branches at the
time of the release so that we can use just 5.x without the SRCREVs being
only on 5.x.x branches?

On Thu, Feb 22, 2018 at 6:27 PM, Samuli Piippo 
wrote:

> Note that the Qt release branches (5.x.x) will usually disappear right
> after the release, which will break the build without nobranch=1
>
> On 22 February 2018 at 19:02, Martin Jansa  wrote:
> > * sneaked in with:
> >   commit 333949a8239dfa7788b35f1059614733e11a6a25
> >   Author: Samuli Piippo 
> >   Date:   Thu Jan 26 16:54:50 2017 +0200
> >
> > Upgrade to Qt 5.8
> > * use 5.10.1 branch by defaut and fix QT_MODULE_BRANCH
> >   in qtknx, qtmqtt, qtwebkit-examples, qtwebkit which don't
> >   have 5.10.1 branch at all
> >
> > Signed-off-by: Martin Jansa 
> > ---
> >  recipes-qt/qt5/qt5-git.inc  | 6 +++---
> >  recipes-qt/qt5/qtknx_git.bb | 2 ++
> >  recipes-qt/qt5/qtmqtt_git.bb| 2 ++
> >  recipes-qt/qt5/qtwebkit-examples_git.bb | 2 ++
> >  recipes-qt/qt5/qtwebkit_git.bb  | 2 ++
> >  5 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/recipes-qt/qt5/qt5-git.inc b/recipes-qt/qt5/qt5-git.inc
> > index 7ee0643..beba913 100644
> > --- a/recipes-qt/qt5/qt5-git.inc
> > +++ b/recipes-qt/qt5/qt5-git.inc
> > @@ -1,9 +1,9 @@
> >  # Copyright (C) 2012-2016 O.S. Systems Software LTDA.
> > -# Copyright (C) 2013-2017 Martin Jansa 
> > +# Copyright (C) 2013-2018 Martin Jansa 
> >
> >  QT_MODULE ?= "${BPN}"
> > -QT_MODULE_BRANCH ?= "5.10"
> > -QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH};nobranch=1"
> > +QT_MODULE_BRANCH ?= "5.10.1"
> > +QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH}"
> >
> >  # each module needs to define valid SRCREV
> >  SRC_URI = " \
> > diff --git a/recipes-qt/qt5/qtknx_git.bb b/recipes-qt/qt5/qtknx_git.bb
> > index 5e01e3c..fa981ab 100644
> > --- a/recipes-qt/qt5/qtknx_git.bb
> > +++ b/recipes-qt/qt5/qtknx_git.bb
> > @@ -9,4 +9,6 @@ LIC_FILES_CHKSUM = " \
> >
> >  DEPENDS += "qtbase"
> >
> > +QT_MODULE_BRANCH = "5.10"
> > +
> >  SRCREV = "29c34e8f072afd01002ed3847d752b4e065f977e"
> > diff --git a/recipes-qt/qt5/qtmqtt_git.bb b/recipes-qt/qt5/qtmqtt_git.bb
> > index b705f7c..90c255d 100644
> > --- a/recipes-qt/qt5/qtmqtt_git.bb
> > +++ b/recipes-qt/qt5/qtmqtt_git.bb
> > @@ -9,4 +9,6 @@ LIC_FILES_CHKSUM = " \
> >
> >  DEPENDS += "qtbase"
> >
> > +QT_MODULE_BRANCH = "5.10"
> > +
> >  SRCREV = "2c3c2a41c55a179332ec2a076856990f36dd5ef9"
> > diff --git a/recipes-qt/qt5/qtwebkit-examples_git.bb b/recipes-qt/qt5/
> qtwebkit-examples_git.bb
> > index 3e3e4a0..114fab7 100644
> > --- a/recipes-qt/qt5/qtwebkit-examples_git.bb
> > +++ b/recipes-qt/qt5/qtwebkit-examples_git.bb
> > @@ -17,4 +17,6 @@ DEPENDS += "qtwebkit qtxmlpatterns"
> >  RDEPENDS_${PN}-examples += "qtwebkit-qmlplugins"
> >  RDEPENDS_${PN}-examples += "${@bb.utils.contains('PACKAGECONFIG_OPENSSL',
> 'openssl', 'ca-certificates', '', d)}"
> >
> > +QT_MODULE_BRANCH = "5.9"
> > +
> >  SRCREV = "a24c780b60d7d8bc00c4a48042cf7f32db777d55"
> > diff --git a/recipes-qt/qt5/qtwebkit_git.bb b/recipes-qt/qt5/
> qtwebkit_git.bb
> > index 5dee6a4..b23d4d6 100644
> > --- a/recipes-qt/qt5/qtwebkit_git.bb
> > +++ b/recipes-qt/qt5/qtwebkit_git.bb
> > @@ -87,4 +87,6 @@ PACKAGES_remove = "${PN}-examples-dev
> ${PN}-examples-staticdev ${PN}-examples-db
> >  RUBY_SYS = "${@ '${BUILD_SYS}'.replace('i486', 'i386').replace('i586',
> 'i386').replace('i686', 'i386') }"
> >  export RUBYLIB="${STAGING_DATADIR_NATIVE}/rubygems:${STAGING_
> LIBDIR_NATIVE}/ruby:${STAGING_LIBDIR_NATIVE}/ruby/${RUBY_SYS}"
> >
> > +QT_MODULE_BRANCH = "5.9"
> > +
> >  SRCREV = "97c4a80a1282c8c3eaa343011286b76fd4838c5f"
> > --
> > 2.15.1
> >
> > --
> > ___
> > 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

[oe] [meta-qt5][rocko][PATCH] qt5-git.inc: drop nobranch=1

[Martin Jansa]

* sneaked in with:
  commit 333949a8239dfa7788b35f1059614733e11a6a25
  Author: Samuli Piippo 
  Date:   Thu Jan 26 16:54:50 2017 +0200

Upgrade to Qt 5.8

Signed-off-by: Martin Jansa 
---
 recipes-qt/qt5/qt5-git.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-qt/qt5/qt5-git.inc b/recipes-qt/qt5/qt5-git.inc
index 44f8d71..796f105 100644
--- a/recipes-qt/qt5/qt5-git.inc
+++ b/recipes-qt/qt5/qt5-git.inc
@@ -3,7 +3,7 @@
 
 QT_MODULE ?= "${BPN}"
 QT_MODULE_BRANCH ?= "5.9"
-QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH};nobranch=1"
+QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH}"
 
 # each module needs to define valid SRCREV
 SRC_URI = " \
-- 
2.15.1

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

[oe] Product platforms based on OE

[Peter Kjellerstedt]

Since the subject of how to manage product platforms based on OE 
interests me very much, I took the liberty of giving this discussion 
its own subject since it really hasn't got much to do with the 
original discussion about splitting meta-oe.

> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Otavio Salvador
> Sent: den 22 februari 2018 10:41
> To: Patrick Ohly 
> Cc: OpenEmbedded Devel List 
> Subject: Re: [oe] Splitting meta-oe?
> 
> On Thu, Feb 22, 2018 at 6:27 AM, Patrick Ohly  wrote:
> > On Thu, 2018-02-22 at 07:53 +0100, Jonas Bonn wrote:
> >> 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.
> >
> > refkit used the same approach. One thing that I would prefer to do
> > differently is the location of the submodule: having them in their own
> > directory would make it more transparent which code is "external" and
> > which is "internal".
> >
> >> "env" is a script containing just the following:
> >> . ./oe-core/oe-init-build-env build/ bitbake/
> >
> > We ended up with a top-level "oe-init-build-env" wrapper script around
> > the actual oe-core/oe-init-build-env. That way the repo could be used
> > the same way as poky. The script sets TEMPLATECONF, so the usual local
> > build setup happens based on refkit sample files.
> 
> We have a script set and a document which describes how we do it:
> 
> http://doc.ossystems.com.br/managing-platforms.html
> 
> The script sources can be seen at:
> 
> https://code.ossystems.com.br/gitweb?p=ossystems-yocto-base-scripts.git
> 
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750

As I see it there are two major use cases for how you work with layers. 

One is the ad hoc method, where you start with some base set of layers, 
e.g., Poky and then add layers as you need using, e.g., bitbake-layers.
When you want to build something else you start over. This method is 
what BitBake and OE Core currently provides.

The second method is the case where you have a well-defined set of 
layers for your project. Typically you want to build a specific product, 
and what layers are needed to do that is specified by someone else. 
Anyone who builds the same product uses the same set of layers. The 
set of layers are typically defined in some kind of manifest (e.g., as 
a Git repository with submodules as Martin mentions above or as a 
repo manifest as Otavio uses).

Since I work for a company where we have some 80+ products that we can 
build based on OE, I will concern myself with the second method.

We too base our platform on repo manifests. We store all our manifests 
in a single Git repository. Whenever a new project starts, they add a 
new manifest that specifies the layers they need. Typically this is done 
by referencing the manifest for our base platform and then add the 
project specific layer(s). This makes it very easy to add a new project, 
as the manifest file typically just looks something like:



  

  


cvp.xml is the platform manifest for our Core Video Platform and is 
used by all our video products. It is actually a symbolic link to 
the CVP manifest for the current version 

Re: [oe] [meta-qt5][PATCHv2] qt5-git.inc: drop nobranch=1

[Samuli Piippo]

Note that the Qt release branches (5.x.x) will usually disappear right
after the release, which will break the build without nobranch=1

On 22 February 2018 at 19:02, Martin Jansa  wrote:
> * sneaked in with:
>   commit 333949a8239dfa7788b35f1059614733e11a6a25
>   Author: Samuli Piippo 
>   Date:   Thu Jan 26 16:54:50 2017 +0200
>
> Upgrade to Qt 5.8
> * use 5.10.1 branch by defaut and fix QT_MODULE_BRANCH
>   in qtknx, qtmqtt, qtwebkit-examples, qtwebkit which don't
>   have 5.10.1 branch at all
>
> Signed-off-by: Martin Jansa 
> ---
>  recipes-qt/qt5/qt5-git.inc  | 6 +++---
>  recipes-qt/qt5/qtknx_git.bb | 2 ++
>  recipes-qt/qt5/qtmqtt_git.bb| 2 ++
>  recipes-qt/qt5/qtwebkit-examples_git.bb | 2 ++
>  recipes-qt/qt5/qtwebkit_git.bb  | 2 ++
>  5 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-qt/qt5/qt5-git.inc b/recipes-qt/qt5/qt5-git.inc
> index 7ee0643..beba913 100644
> --- a/recipes-qt/qt5/qt5-git.inc
> +++ b/recipes-qt/qt5/qt5-git.inc
> @@ -1,9 +1,9 @@
>  # Copyright (C) 2012-2016 O.S. Systems Software LTDA.
> -# Copyright (C) 2013-2017 Martin Jansa 
> +# Copyright (C) 2013-2018 Martin Jansa 
>
>  QT_MODULE ?= "${BPN}"
> -QT_MODULE_BRANCH ?= "5.10"
> -QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH};nobranch=1"
> +QT_MODULE_BRANCH ?= "5.10.1"
> +QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH}"
>
>  # each module needs to define valid SRCREV
>  SRC_URI = " \
> diff --git a/recipes-qt/qt5/qtknx_git.bb b/recipes-qt/qt5/qtknx_git.bb
> index 5e01e3c..fa981ab 100644
> --- a/recipes-qt/qt5/qtknx_git.bb
> +++ b/recipes-qt/qt5/qtknx_git.bb
> @@ -9,4 +9,6 @@ LIC_FILES_CHKSUM = " \
>
>  DEPENDS += "qtbase"
>
> +QT_MODULE_BRANCH = "5.10"
> +
>  SRCREV = "29c34e8f072afd01002ed3847d752b4e065f977e"
> diff --git a/recipes-qt/qt5/qtmqtt_git.bb b/recipes-qt/qt5/qtmqtt_git.bb
> index b705f7c..90c255d 100644
> --- a/recipes-qt/qt5/qtmqtt_git.bb
> +++ b/recipes-qt/qt5/qtmqtt_git.bb
> @@ -9,4 +9,6 @@ LIC_FILES_CHKSUM = " \
>
>  DEPENDS += "qtbase"
>
> +QT_MODULE_BRANCH = "5.10"
> +
>  SRCREV = "2c3c2a41c55a179332ec2a076856990f36dd5ef9"
> diff --git a/recipes-qt/qt5/qtwebkit-examples_git.bb 
> b/recipes-qt/qt5/qtwebkit-examples_git.bb
> index 3e3e4a0..114fab7 100644
> --- a/recipes-qt/qt5/qtwebkit-examples_git.bb
> +++ b/recipes-qt/qt5/qtwebkit-examples_git.bb
> @@ -17,4 +17,6 @@ DEPENDS += "qtwebkit qtxmlpatterns"
>  RDEPENDS_${PN}-examples += "qtwebkit-qmlplugins"
>  RDEPENDS_${PN}-examples += "${@bb.utils.contains('PACKAGECONFIG_OPENSSL', 
> 'openssl', 'ca-certificates', '', d)}"
>
> +QT_MODULE_BRANCH = "5.9"
> +
>  SRCREV = "a24c780b60d7d8bc00c4a48042cf7f32db777d55"
> diff --git a/recipes-qt/qt5/qtwebkit_git.bb b/recipes-qt/qt5/qtwebkit_git.bb
> index 5dee6a4..b23d4d6 100644
> --- a/recipes-qt/qt5/qtwebkit_git.bb
> +++ b/recipes-qt/qt5/qtwebkit_git.bb
> @@ -87,4 +87,6 @@ PACKAGES_remove = "${PN}-examples-dev 
> ${PN}-examples-staticdev ${PN}-examples-db
>  RUBY_SYS = "${@ '${BUILD_SYS}'.replace('i486', 'i386').replace('i586', 
> 'i386').replace('i686', 'i386') }"
>  export 
> RUBYLIB="${STAGING_DATADIR_NATIVE}/rubygems:${STAGING_LIBDIR_NATIVE}/ruby:${STAGING_LIBDIR_NATIVE}/ruby/${RUBY_SYS}"
>
> +QT_MODULE_BRANCH = "5.9"
> +
>  SRCREV = "97c4a80a1282c8c3eaa343011286b76fd4838c5f"
> --
> 2.15.1
>
> --
> ___
> 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

[oe] [meta-qt5][PATCHv2] qt5-git.inc: drop nobranch=1

[Martin Jansa]

* sneaked in with:
  commit 333949a8239dfa7788b35f1059614733e11a6a25
  Author: Samuli Piippo 
  Date:   Thu Jan 26 16:54:50 2017 +0200

Upgrade to Qt 5.8
* use 5.10.1 branch by defaut and fix QT_MODULE_BRANCH
  in qtknx, qtmqtt, qtwebkit-examples, qtwebkit which don't
  have 5.10.1 branch at all

Signed-off-by: Martin Jansa 
---
 recipes-qt/qt5/qt5-git.inc  | 6 +++---
 recipes-qt/qt5/qtknx_git.bb | 2 ++
 recipes-qt/qt5/qtmqtt_git.bb| 2 ++
 recipes-qt/qt5/qtwebkit-examples_git.bb | 2 ++
 recipes-qt/qt5/qtwebkit_git.bb  | 2 ++
 5 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/recipes-qt/qt5/qt5-git.inc b/recipes-qt/qt5/qt5-git.inc
index 7ee0643..beba913 100644
--- a/recipes-qt/qt5/qt5-git.inc
+++ b/recipes-qt/qt5/qt5-git.inc
@@ -1,9 +1,9 @@
 # Copyright (C) 2012-2016 O.S. Systems Software LTDA.
-# Copyright (C) 2013-2017 Martin Jansa 
+# Copyright (C) 2013-2018 Martin Jansa 
 
 QT_MODULE ?= "${BPN}"
-QT_MODULE_BRANCH ?= "5.10"
-QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH};nobranch=1"
+QT_MODULE_BRANCH ?= "5.10.1"
+QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH}"
 
 # each module needs to define valid SRCREV
 SRC_URI = " \
diff --git a/recipes-qt/qt5/qtknx_git.bb b/recipes-qt/qt5/qtknx_git.bb
index 5e01e3c..fa981ab 100644
--- a/recipes-qt/qt5/qtknx_git.bb
+++ b/recipes-qt/qt5/qtknx_git.bb
@@ -9,4 +9,6 @@ LIC_FILES_CHKSUM = " \
 
 DEPENDS += "qtbase"
 
+QT_MODULE_BRANCH = "5.10"
+
 SRCREV = "29c34e8f072afd01002ed3847d752b4e065f977e"
diff --git a/recipes-qt/qt5/qtmqtt_git.bb b/recipes-qt/qt5/qtmqtt_git.bb
index b705f7c..90c255d 100644
--- a/recipes-qt/qt5/qtmqtt_git.bb
+++ b/recipes-qt/qt5/qtmqtt_git.bb
@@ -9,4 +9,6 @@ LIC_FILES_CHKSUM = " \
 
 DEPENDS += "qtbase"
 
+QT_MODULE_BRANCH = "5.10"
+
 SRCREV = "2c3c2a41c55a179332ec2a076856990f36dd5ef9"
diff --git a/recipes-qt/qt5/qtwebkit-examples_git.bb 
b/recipes-qt/qt5/qtwebkit-examples_git.bb
index 3e3e4a0..114fab7 100644
--- a/recipes-qt/qt5/qtwebkit-examples_git.bb
+++ b/recipes-qt/qt5/qtwebkit-examples_git.bb
@@ -17,4 +17,6 @@ DEPENDS += "qtwebkit qtxmlpatterns"
 RDEPENDS_${PN}-examples += "qtwebkit-qmlplugins"
 RDEPENDS_${PN}-examples += "${@bb.utils.contains('PACKAGECONFIG_OPENSSL', 
'openssl', 'ca-certificates', '', d)}"
 
+QT_MODULE_BRANCH = "5.9"
+
 SRCREV = "a24c780b60d7d8bc00c4a48042cf7f32db777d55"
diff --git a/recipes-qt/qt5/qtwebkit_git.bb b/recipes-qt/qt5/qtwebkit_git.bb
index 5dee6a4..b23d4d6 100644
--- a/recipes-qt/qt5/qtwebkit_git.bb
+++ b/recipes-qt/qt5/qtwebkit_git.bb
@@ -87,4 +87,6 @@ PACKAGES_remove = "${PN}-examples-dev 
${PN}-examples-staticdev ${PN}-examples-db
 RUBY_SYS = "${@ '${BUILD_SYS}'.replace('i486', 'i386').replace('i586', 
'i386').replace('i686', 'i386') }"
 export 
RUBYLIB="${STAGING_DATADIR_NATIVE}/rubygems:${STAGING_LIBDIR_NATIVE}/ruby:${STAGING_LIBDIR_NATIVE}/ruby/${RUBY_SYS}"
 
+QT_MODULE_BRANCH = "5.9"
+
 SRCREV = "97c4a80a1282c8c3eaa343011286b76fd4838c5f"
-- 
2.15.1

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

[oe] Summary of splitting meta-oe discussion

[Philip Balister]

It looks like there was an in depth discussion of splitting meta-oe
(again). Before everyone forgets, can someone put a summary of the
points on her for discussion at OEDAM?

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

We don't need conclusions or judgements, just make sure your points are
documented.

Bonus points for summaries of the other topics that came up.

Thanks,

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

[oe] [meta-qt5][WIP][PATCH] qt5: upgrade to 5.11 Alpha

[Martin Jansa]

* use qtwebkit and qtwebkit-examples from dev branch, because there is
  no 5.11 branch (there isn't 5.10 as well, but because nobranch=1 in
  qt5-git.inc nobody noticed).

Signed-off-by: Martin Jansa 
---
 recipes-qt/qt5/nativesdk-qtbase_git.bb | 10 ++---
 .../qt5/qt3d/0001-Allow-a-tools-only-build.patch   |  8 ++--
 ...2-Fix-BlenderDNA-for-clang-cross-compiler.patch |  2 +-
 recipes-qt/qt5/qt3d_git.bb |  6 +--
 recipes-qt/qt5/qt5-git.inc |  4 +-
 recipes-qt/qt5/qtbase-native_git.bb|  8 ++--
 .../qt5/qtbase/0001-Add-linux-oe-g-platform.patch  |  4 +-
 ...make-Use-OE_QMAKE_PATH_EXTERNAL_HOST_BINS.patch |  2 +-
 ...o-allow-to-set-qt.conf-from-the-outside-u.patch |  4 +-
 ...ump-path-length-from-256-to-512-character.patch |  6 +--
 ...-unknown-features-instead-of-erroring-out.patch |  2 +-
 ...-wasn-t-found-if-OE_QMAKE_PATH_EXTERNAL_H.patch |  2 +-
 .../0007-Delete-qlonglong-and-qulonglong.patch |  2 +-
 ...08-Replace-pthread_yield-with-sched_yield.patch |  8 ++--
 ...-Add-OE-specific-specs-for-clang-compiler.patch |  2 +-
 ...-Invert-conditional-for-defining-QT_SOCKL.patch |  6 +--
 ..._qlocale-Enable-QT_USE_FENV-only-on-glibc.patch |  4 +-
 ...mon-gcc-base.conf-Use-I-instead-of-isyste.patch |  2 +-
 .../qtbase/0013-Always-build-uic-and-qvkgen.patch  |  6 +--
 .../0014-Bootstrap-without-linkat-feature.patch|  6 +--
 recipes-qt/qt5/qtbase_git.bb   |  6 +--
 recipes-qt/qt5/qtcanvas3d_git.bb   |  2 +-
 recipes-qt/qt5/qtcharts_git.bb |  2 +-
 recipes-qt/qt5/qtconnectivity_git.bb   |  2 +-
 recipes-qt/qt5/qtdatavis3d_git.bb  |  2 +-
 recipes-qt/qt5/qtdeclarative_git.bb|  2 +-
 recipes-qt/qt5/qtgamepad_git.bb|  2 +-
 recipes-qt/qt5/qtgraphicaleffects_git.bb   |  2 +-
 recipes-qt/qt5/qtimageformats_git.bb   |  2 +-
 recipes-qt/qt5/qtknx_git.bb|  2 +-
 recipes-qt/qt5/qtlocation_git.bb   |  2 +-
 recipes-qt/qt5/qtmqtt_git.bb   |  2 +-
 ...tmultimedia-fix-a-conflicting-declaration.patch |  2 +-
 recipes-qt/qt5/qtmultimedia_git.bb |  6 +--
 recipes-qt/qt5/qtnetworkauth_git.bb|  2 +-
 recipes-qt/qt5/qtquick1_git.bb |  2 +-
 recipes-qt/qt5/qtquickcontrols2_git.bb |  2 +-
 recipes-qt/qt5/qtquickcontrols_git.bb  |  2 +-
 .../0001-Allow-a-tools-only-build.patch|  2 +-
 recipes-qt/qt5/qtremoteobjects_git.bb  |  6 +--
 recipes-qt/qt5/qtscript_git.bb |  2 +-
 ...Use-external-host-bin-path-for-cmake-file.patch |  2 +-
 recipes-qt/qt5/qtscxml_git.bb  |  6 +--
 recipes-qt/qt5/qtsensors_git.bb|  2 +-
 recipes-qt/qt5/qtserialbus_git.bb  |  2 +-
 recipes-qt/qt5/qtserialport_git.bb |  2 +-
 recipes-qt/qt5/qtsvg_git.bb|  2 +-
 .../0001-add-noqtwebkit-configuration.patch|  2 +-
 ...ols-cmake-allow-overriding-the-location-f.patch |  2 +-
 recipes-qt/qt5/qttools_git.bb  |  6 +--
 recipes-qt/qt5/qttranslations_git.bb   |  2 +-
 .../0001-include-sys-time.h-for-timeval.patch  |  2 +-
 recipes-qt/qt5/qtvirtualkeyboard_git.bb|  6 +--
 .../0001-fix-build-without-xkbcommon-evdev.patch   | 12 +++---
 recipes-qt/qt5/qtwayland_git.bb|  6 +--
 recipes-qt/qt5/qtwebchannel_git.bb |  2 +-
 ...quickwebengineview_p_p.h-add-include-QCol.patch |  6 +--
 ...romium-Force-host-toolchain-configuration.patch |  6 +--
 ...-dependency-to-QCoreApplication-translate.patch |  2 +-
 ...um-workaround-for-too-long-.rps-file-name.patch |  2 +-
 .../0003-Force-host-toolchain-configuration.patch  |  6 +--
 ...sl-sandbox-Define-TEMP_FAILURE_RETRY-if-n.patch |  2 +-
 ...sl-Avoid-mallinfo-APIs-on-non-glibc-linux.patch |  6 +--
 ...use-pvalloc-as-it-s-not-available-on-musl.patch |  2 +-
 ...-chromium-musl-include-fcntl.h-for-loff_t.patch |  2 +-
 .../0005-musl-link-against-libexecinfo.patch   |  2 +-
 ...sl-use-off64_t-instead-of-the-internal-__.patch |  2 +-
 ...ium-musl-linux-glibc-make-the-distinction.patch |  2 +-
 ...sl-allocator-Do-not-include-glibc_weak_sy.patch |  2 +-
 ...sl-Use-correct-member-name-__si_fields-fr.patch |  2 +-
 ...l-Define-res_ninit-and-res_nclose-for-no.patch} |  6 +--
 ...hromium-musl-Match-syscalls-to-match-musl.patch | 44 --
 ...romium-musl-Do-not-define-__sbrk-on-musl.patch} |  2 +-
 ...m-musl-Adjust-default-pthread-stack-size.patch} |  6 +--
 ...l-include-asm-generic-ioctl.h-for-TCGETS.patch} |  4 +-
 ...l-tcmalloc-Use-off64_t-insread-of-__off6.patch} |  2 +-
 recipes-qt/qt5/qtwebengine_git.bb  | 25 ++--
 recipes-qt/qt5/qtwebkit-examples_git.bb|  4 +-
 

[oe] [meta-qt5][PATCH] qt5-git.inc: drop nobranch=1

[Martin Jansa]

* sneaked in with:
  commit 333949a8239dfa7788b35f1059614733e11a6a25
  Author: Samuli Piippo 
  Date:   Thu Jan 26 16:54:50 2017 +0200

Upgrade to Qt 5.8

Signed-off-by: Martin Jansa 
---
 recipes-qt/qt5/qt5-git.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-qt/qt5/qt5-git.inc b/recipes-qt/qt5/qt5-git.inc
index 7ee0643..37c742f 100644
--- a/recipes-qt/qt5/qt5-git.inc
+++ b/recipes-qt/qt5/qt5-git.inc
@@ -1,9 +1,9 @@
 # Copyright (C) 2012-2016 O.S. Systems Software LTDA.
-# Copyright (C) 2013-2017 Martin Jansa 
+# Copyright (C) 2013-2018 Martin Jansa 
 
 QT_MODULE ?= "${BPN}"
 QT_MODULE_BRANCH ?= "5.10"
-QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH};nobranch=1"
+QT_MODULE_BRANCH_PARAM ?= "branch=${QT_MODULE_BRANCH}"
 
 # each module needs to define valid SRCREV
 SRC_URI = " \
-- 
2.15.1

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

[oe] [meta-qt5][PATCH] qt5: refresh patches from meta-qt5/qt* repos

[Martin Jansa]

* apply:
  0012-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch
  also for nativesdk-qtbase as the comment says
* drop unused:
  0001-Add-missing-include-for-struct-timeval.patch
  which wasn't removed in 5.10.1 upgrade

Signed-off-by: Martin Jansa 
---
 recipes-qt/qt5/nativesdk-qtbase_git.bb |  7 +++---
 .../qt5/qt3d/0001-Allow-a-tools-only-build.patch   |  2 +-
 ...2-Fix-BlenderDNA-for-clang-cross-compiler.patch |  2 +-
 recipes-qt/qt5/qt3d_git.bb |  2 +-
 recipes-qt/qt5/qtbase-native_git.bb| 10 -
 .../qt5/qtbase/0001-Add-linux-oe-g-platform.patch  |  2 +-
 ...make-Use-OE_QMAKE_PATH_EXTERNAL_HOST_BINS.patch |  2 +-
 ...o-allow-to-set-qt.conf-from-the-outside-u.patch |  2 +-
 ...ump-path-length-from-256-to-512-character.patch |  4 ++--
 ...-unknown-features-instead-of-erroring-out.patch |  6 +++---
 ...-wasn-t-found-if-OE_QMAKE_PATH_EXTERNAL_H.patch |  2 +-
 .../0007-Delete-qlonglong-and-qulonglong.patch |  2 +-
 ...08-Replace-pthread_yield-with-sched_yield.patch |  6 +++---
 ...-Add-OE-specific-specs-for-clang-compiler.patch |  2 +-
 ...-Invert-conditional-for-defining-QT_SOCKL.patch |  2 +-
 ..._qlocale-Enable-QT_USE_FENV-only-on-glibc.patch |  2 +-
 ...on-gcc-base.conf-Use-I-instead-of-isyste.patch} |  7 ++
 ...atch => 0013-Always-build-uic-and-qvkgen.patch} |  6 +++---
 ...=> 0014-Bootstrap-without-linkat-feature.patch} |  2 +-
 recipes-qt/qt5/qtbase_git.bb   |  4 ++--
 ...tmultimedia-fix-a-conflicting-declaration.patch |  2 +-
 recipes-qt/qt5/qtmultimedia_git.bb |  2 +-
 .../0001-Allow-a-tools-only-build.patch|  2 +-
 recipes-qt/qt5/qtremoteobjects_git.bb  |  2 +-
 ...Use-external-host-bin-path-for-cmake-file.patch |  2 +-
 recipes-qt/qt5/qtscxml_git.bb  |  2 +-
 ...01-Add-missing-include-for-struct-timeval.patch | 25 --
 .../0001-add-noqtwebkit-configuration.patch|  2 +-
 ...ols-cmake-allow-overriding-the-location-f.patch |  2 +-
 recipes-qt/qt5/qttools_git.bb  |  2 +-
 .../0001-include-sys-time.h-for-timeval.patch  |  2 +-
 recipes-qt/qt5/qtvirtualkeyboard_git.bb|  2 +-
 .../0001-fix-build-without-xkbcommon-evdev.patch   |  2 +-
 recipes-qt/qt5/qtwayland_git.bb|  2 +-
 ...quickwebengineview_p_p.h-add-include-QCol.patch |  4 ++--
 ...romium-Force-host-toolchain-configuration.patch |  2 +-
 ...-dependency-to-QCoreApplication-translate.patch |  2 +-
 ...um-workaround-for-too-long-.rps-file-name.patch |  2 +-
 .../0003-Force-host-toolchain-configuration.patch  |  4 ++--
 ...sl-sandbox-Define-TEMP_FAILURE_RETRY-if-n.patch |  2 +-
 ...sl-Avoid-mallinfo-APIs-on-non-glibc-linux.patch |  2 +-
 ...use-pvalloc-as-it-s-not-available-on-musl.patch |  2 +-
 ...-chromium-musl-include-fcntl.h-for-loff_t.patch |  2 +-
 .../0005-musl-link-against-libexecinfo.patch   |  6 +++---
 ...sl-use-off64_t-instead-of-the-internal-__.patch |  2 +-
 ...ium-musl-linux-glibc-make-the-distinction.patch |  2 +-
 ...sl-allocator-Do-not-include-glibc_weak_sy.patch |  2 +-
 ...sl-Use-correct-member-name-__si_fields-fr.patch |  2 +-
 ...hromium-musl-Match-syscalls-to-match-musl.patch |  2 +-
 ...sl-Define-res_ninit-and-res_nclose-for-no.patch |  2 +-
 ...hromium-musl-Do-not-define-__sbrk-on-musl.patch |  2 +-
 ...um-musl-Adjust-default-pthread-stack-size.patch |  2 +-
 ...sl-include-asm-generic-ioctl.h-for-TCGETS.patch |  2 +-
 ...sl-tcmalloc-Use-off64_t-insread-of-__off6.patch |  2 +-
 recipes-qt/qt5/qtwebengine_git.bb  |  4 ++--
 55 files changed, 75 insertions(+), 102 deletions(-)
 rename 
recipes-qt/qt5/qtbase/{0014-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch
 => 0012-mkspecs-common-gcc-base.conf-Use-I-instead-of-isyste.patch} (91%)
 rename recipes-qt/qt5/qtbase/{0012-Always-build-uic-and-qvkgen.patch => 
0013-Always-build-uic-and-qvkgen.patch} (84%)
 rename recipes-qt/qt5/qtbase/{0013-Bootstrap-without-linkat-feature.patch => 
0014-Bootstrap-without-linkat-feature.patch} (92%)
 delete mode 100644 
recipes-qt/qt5/qtserialbus/0001-Add-missing-include-for-struct-timeval.patch

diff --git a/recipes-qt/qt5/nativesdk-qtbase_git.bb 
b/recipes-qt/qt5/nativesdk-qtbase_git.bb
index fb2f76e..efcb82c 100644
--- a/recipes-qt/qt5/nativesdk-qtbase_git.bb
+++ b/recipes-qt/qt5/nativesdk-qtbase_git.bb
@@ -26,7 +26,7 @@ FILESEXTRAPATHS =. "${FILE_DIRNAME}/qtbase:"
 
 # common for qtbase-native, qtbase-nativesdk and qtbase
 # Patches from https://github.com/meta-qt5/qtbase/commits/b5.10-shared
-# 5.10.meta-qt5-shared.1
+# 5.10.meta-qt5-shared.2
 SRC_URI += "\
 file://0001-Add-linux-oe-g-platform.patch \
 file://0002-cmake-Use-OE_QMAKE_PATH_EXTERNAL_HOST_BINS.patch \
@@ -39,13 +39,14 @@ SRC_URI += "\
 file://0009-Add-OE-specific-specs-for-clang-compiler.patch \
 file://0010-linux-clang-Invert-conditional-for-defining-QT_SOCKL.patch \
 

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

[Måns Zigher]

Not sure if this is the right way to solve it but since all the recipes
have there own sysroot you need to make sure that the QT_INSTALL_PREFIX is
pointing to the right sysroot it should not point to the qt4-native sysroot
since that might not exist especially if using rm_work.
Create a qt.conf file for your recipe and and then implement a
do_configure_prepand where you set the QT_INSTALL_PREFIX to point to the
recipe sysroot. My ended up looking like this.

[Paths]
Prefix = "@WORKDIR@/recipe-sysroot-native/"
Binaries = "usr/bin"

in do_configure_prepand

do_configure_prepend() {
sed -i -e 's,@WORKDIR@,${WORKDIR},g' ${WORKDIR}/qt.conf
}

This solved my problem I still couldn't figure out if the qt4-native is
actually broken or if this is the way it should work now that each recipe
have it's own sysroot.

BR
Mans Zigher

2018-02-21 16:49 GMT+01:00 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-nat
>> ive/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-nat
>> ive/4.8.7-r0/recipe-sysroot-native/usr/lib/qt4/plugins
>>
>>
>> QT_INSTALL_IMPORTS:/home/build/tmp/work/x86_64-linux/qt4-nat
>> ive/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/q
>> t4-native/4.8.7-r0/recipe-sysroot-native/etc/qt4
>>
>>
>> QT_INSTALL_EXAMPLES:/home/build/tmp/work/x86_64-linux/qt4-na
>> tive/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/
 

Re: [oe] Splitting meta-oe?

[Otavio Salvador]

On Thu, Feb 22, 2018 at 6:27 AM, Patrick Ohly  wrote:
> On Thu, 2018-02-22 at 07:53 +0100, Jonas Bonn wrote:
>> 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.
>
> refkit used the same approach. One thing that I would prefer to do
> differently is the location of the submodule: having them in their own
> directory would make it more transparent which code is "external" and
> which is "internal".
>
>> "env" is a script containing just the following:
>> . ./oe-core/oe-init-build-env build/ bitbake/
>
> We ended up with a top-level "oe-init-build-env" wrapper script around
> the actual oe-core/oe-init-build-env. That way the repo could be used
> the same way as poky. The script sets TEMPLATECONF, so the usual local
> build setup happens based on refkit sample files.

We have a script set and a document which describes how we do it:

http://doc.ossystems.com.br/managing-platforms.html

The script sources can be seen at:

https://code.ossystems.com.br/gitweb?p=ossystems-yocto-base-scripts.git

-- 
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 Thu, 2018-02-22 at 07:53 +0100, Jonas Bonn wrote:
> 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.

refkit used the same approach. One thing that I would prefer to do
differently is the location of the submodule: having them in their own
directory would make it more transparent which code is "external" and
which is "internal".

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

We ended up with a top-level "oe-init-build-env" wrapper script around
the actual oe-core/oe-init-build-env. That way the repo could be used
the same way as poky. The script sets TEMPLATECONF, so the usual local
build setup happens based on refkit sample files.

-- 
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] Splitting meta-oe?

[Patrick Ohly]

On Wed, 2018-02-21 at 20:33 +0100, Andreas Oberritter wrote:
> On Wed, 21 Feb 2018 15:58:17 +0100
> Patrick Ohly  wrote:
> > 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?

No, not at the moment.

-- 
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] libtalloc failure due to waf

[Tim Orling]

I automatically sync about 12 layers every day. This is a show stopper
because it breaks that workflow and forces a deviation from just building
on “master”. I am now about two months behind “master” for various reasons,
but this is the one remaining blocker. I have zero interest in carrying
local patches for this. Just frustrated. I wish I had a suggestion for a
better way.

In particular, this points out the frailty of bbclasses not having a
mechanism like bbapends. It is invasive to fix this locally. Or I am just
being dumb. And frustrated. And should be sleeping now.
On Thu, Feb 22, 2018 at 12:48 AM Martin Jansa 
wrote:

> +Joe who will merge it to meta-networking
>
> maybe you meant show stopper as libtalloc failure not the whole OE world
> failing to parse because of waf-samba.bbclass (even if you don't build any
> recipes using it).
>
> FWIW: I've also sent simple fix for that to oe-core a while ago:
>
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master=71debaa06cb6f0d8996527e6d3bd6634508bd4a5
> that's why it isn't failing for me, but it wasn't merged to oe-core and not
> sure if it ever will be.
>
> Regards,
>
>
> On Thu, Feb 22, 2018 at 9:30 AM, Martin Jansa 
> wrote:
>
> > I've merged the fix for parsing issues immediately after sending it (6
> > days ago):
> > http://git.openembedded.org/meta-openembedded/commit/?id=2f7
> > de931885c1b9e63c4e4238f0f7ad1388e8b6d
> >
> > So it shouldn't fail to parse for you if you use new enough oe-core (it
> > doesn't fail for me).
> >
> > waf.bbclass is still broken in rocko and master, but that's different
> > issue and not as fatal as missing get_waf_parallel_make function.
> >
> > On Thu, Feb 22, 2018 at 3:48 AM, Tim Orling
>  > com> wrote:
> >
> >> 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 

Re: [oe] libtalloc failure due to waf

[Martin Jansa]

+Joe who will merge it to meta-networking

maybe you meant show stopper as libtalloc failure not the whole OE world
failing to parse because of waf-samba.bbclass (even if you don't build any
recipes using it).

FWIW: I've also sent simple fix for that to oe-core a while ago:
http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master=71debaa06cb6f0d8996527e6d3bd6634508bd4a5
that's why it isn't failing for me, but it wasn't merged to oe-core and not
sure if it ever will be.

Regards,


On Thu, Feb 22, 2018 at 9:30 AM, Martin Jansa 
wrote:

> I've merged the fix for parsing issues immediately after sending it (6
> days ago):
> http://git.openembedded.org/meta-openembedded/commit/?id=2f7
> de931885c1b9e63c4e4238f0f7ad1388e8b6d
>
> So it shouldn't fail to parse for you if you use new enough oe-core (it
> doesn't fail for me).
>
> waf.bbclass is still broken in rocko and master, but that's different
> issue and not as fatal as missing get_waf_parallel_make function.
>
> On Thu, Feb 22, 2018 at 3:48 AM, Tim Orling  com> wrote:
>
>> 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
>> 
>> 

Re: [oe] libtalloc failure due to waf

[Martin Jansa]

I've merged the fix for parsing issues immediately after sending it (6 days
ago):
http://git.openembedded.org/meta-openembedded/commit/?id=2f7de931885c1b9e63c4e4238f0f7ad1388e8b6d

So it shouldn't fail to parse for you if you use new enough oe-core (it
doesn't fail for me).

waf.bbclass is still broken in rocko and master, but that's different issue
and not as fatal as missing get_waf_parallel_make function.

On Thu, Feb 22, 2018 at 3:48 AM, Tim Orling <
timothy.t.orl...@linux.intel.com> wrote:

> 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?
> 
> >>
> 

[oe] [RFC] Rename meta-openembedded to openembedded-extras

[Andrea Adami]

All,
it seems there is some consensus about reordering/cleaning the
"OpenEmbedded layers".

I think that before starting any cleaning *inside* we should finally
clean up the confusion about meta-oe meta-openembedded
openembedded-layers, etc..

I think it would be advisable to rename the repository from
meta-openembedded to openembedded-extras, matching the
openembedded-core naming schema.

Regards
Andrea


P.S.
One layer of this repo would be the (in)famous meta-oe.
I can't imagine right now a definition for it: it contains old
versions of oe-core recipes, expunged recipes, tools and libraries
needed by other layers (i.e. tslib), etc. etc.
This one will need a separate thread.
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel