[oe] [meta-python2][PATCH] layer.conf: switch to langdale
To ensure that this branch can still be used with OE-core.
Signed-off-by: Nicolas Dechesne
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/conf/layer.conf b/conf/layer.conf
index 38ef579..781884c 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,7 +14,7 @@ LAYERVERSION_meta-python2 = "1"
LAYERDEPENDS_meta-python2 = "core openembedded-layer"
-LAYERSERIES_COMPAT_meta-python2 = "kirkstone"
+LAYERSERIES_COMPAT_meta-python2 = "langdale"
LICENSE_PATH += "${LAYERDIR}/licenses"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#99115):
https://lists.openembedded.org/g/openembedded-devel/message/99115
Mute This Topic: https://lists.openembedded.org/mt/94231540/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-oe][PATCH] gpsd-machine-conf: allow creation of an empty package
On Wed, Jun 22, 2022 at 12:42 AM Fabien Parent
wrote:
> gpsd-machine-conf is an empty recipe that does not ship any files on the
> rootfs. This recipe is targeted to be extended by a bbappend that
> will provide the gpsd machine configuration.
>
> In the case where gpsd-machine-conf is included into an image, and if no
> layers is providing the machine configuration, the build fails with
> the following error:
>
> No match for argument: gpsd-machine-conf
> Error: Unable to find a match: gpsd-machine-conf
>
> This error is because no package was created for gpsd-machine-conf
> since the recipe does not install any files.
>
It is worth mentioning that this is a new/recent issue which has been
around since June 7 in our CI. Looks like it came after we upgraded opkg to
0.6.0 [1], and the opkg 0.6.0 release notes [2] have this item:
- libsolv will now return a solver error if the user asks to install a
package which does not exist in the feeds.
So it might impact other recipes in case this 'pattern' is used elsewhere.
[1] 1e08da6a4387 (opkg: upgrade to version 0.6.0)
[2] http://downloads.yoctoproject.org/releases/opkg/opkg-0.6.0.release-notes
>
> This commit allows the creation of an empty package in order to avoid
> the do_rootfs failure when this package is included into an image.
>
> Signed-off-by: Fabien Parent
> ---
> meta-oe/recipes-navigation/gpsd/gpsd-machine-conf_1.0.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta-oe/recipes-navigation/gpsd/gpsd-machine-conf_1.0.bb
> b/meta-oe/recipes-navigation/gpsd/gpsd-machine-conf_1.0.bb
> index 9c1db3a6b0b1..4ced1c98db6f 100644
> --- a/meta-oe/recipes-navigation/gpsd/gpsd-machine-conf_1.0.bb
> +++ b/meta-oe/recipes-navigation/gpsd/gpsd-machine-conf_1.0.bb
> @@ -5,3 +5,4 @@ LIC_FILES_CHKSUM =
> "file://${COREBASE}/meta/files/common-licenses/BSD-3-Clause;m
> # empty by default
> # BSP layers can add stuff like meta-openmoko example:
> #
> +ALLOW_EMPTY:${PN} = "1"
> --
> 2.36.1
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#97558):
https://lists.openembedded.org/g/openembedded-devel/message/97558
Mute This Topic: https://lists.openembedded.org/mt/91911096/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-oe][PATCH] imlib2: update SRC_URI
On Mon, May 16, 2022 at 7:59 PM Khem Raj wrote:
>
>
> On Mon, May 16, 2022 at 10:45 AM Nicolas Dechesne <
> nicolas.deche...@linaro.org> wrote:
>
>>
>>
>> On Mon, May 16, 2022 at 6:09 PM Khem Raj wrote:
>>
>>>
>>>
>>> On 5/16/22 8:28 AM, Zoltan Boszormenyi via lists.openembedded.org wrote:
>>> > 2022. 05. 10. 11:28 keltezéssel, Nicolas Dechesne írta:
>>> >> The upstream repo location has changed, it's now
>>> >> https://git.enlightenment.org/old/legacy-imlib2
>>> >
>>> > This hits every branch in meta-openembedded, not only master.
>>> >
>>>
>>> A different patch fixing same thing is already in master.
>>>
>>
>> This is the merged patch, e.g.
>> 62becef1091d (imlib2: update SRC_URI)
>>
>> Not sure what you meant.
>>
>
>
> I had the thread broken I should have said this patch is upstream in
> master already if needed send backport request for respective release
> branches
>
ok, done for honister and kirkstone
> And yes, it's needed in all branches. Do you want/need a patch for this,
>> or can you backport/apply directly?
>>
>>>
>>> >>
>>> >> It's not clear when or why it happened, but the the commit hash we use
>>> >> in SRCREV exists in the 'new' location, so let's at least update the
>>> >> SRC_URI for now, and fix this warning:
>>> >>
>>> >> WARNING: imlib2-1.7.1-r0 do_fetch: Failed to fetch URL
>>> >> git://
>>> git.enlightenment.org/legacy/imlib2.git;protocol=https;branch=master,
>>> >> attempting MIRRORS if available
>>> >>
>>> >> Signed-off-by: Nicolas Dechesne
>>> >> ---
>>> >> meta-oe/recipes-graphics/imlib2/imlib2_git.bb | 2 +-
>>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
>>> >> b/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
>>> >> index 56d41cd39..869f8123d 100644
>>> >> --- a/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
>>> >> +++ b/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
>>> >> @@ -14,7 +14,7 @@ inherit autotools pkgconfig lib_package
>>> >> AUTO_LIBNAME_PKGS = ""
>>> >> -SRC_URI =
>>> >> "git://
>>> git.enlightenment.org/legacy/${BPN}.git;protocol=https;branch=master
>>> <http://git.enlightenment.org/legacy/$%7BBPN%7D.git;protocol=https;branch=master>"
>>>
>>> >>
>>> >> +SRC_URI =
>>> >> "git://
>>> git.enlightenment.org/old/legacy-${BPN}.git;protocol=https;branch=master
>>> <http://git.enlightenment.org/old/legacy-$%7BBPN%7D.git;protocol=https;branch=master>"
>>>
>>> >>
>>> >> S = "${WORKDIR}/git"
>>> >> PACKAGECONFIG ??= "jpeg png zlib
>>> >> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#97144):
https://lists.openembedded.org/g/openembedded-devel/message/97144
Mute This Topic: https://lists.openembedded.org/mt/91008939/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-oe][honister][PATCH] imlib2: update SRC_URI
The upstream repo location has changed, it's now
https://git.enlightenment.org/old/legacy-imlib2
It's not clear when or why it happened, but the the commit hash we use
in SRCREV exists in the 'new' location, so let's at least update the
SRC_URI for now, and fix this warning:
WARNING: imlib2-1.7.1-r0 do_fetch: Failed to fetch URL
git://git.enlightenment.org/legacy/imlib2.git;protocol=https;branch=master,
attempting MIRRORS if available
Signed-off-by: Nicolas Dechesne
Signed-off-by: Khem Raj
(cherry picked from commit 62becef1091d21f487e826df7be7dcef3ab8f94c)
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-graphics/imlib2/imlib2_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
b/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
index 56d41cd39..869f8123d 100644
--- a/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
+++ b/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
@@ -14,7 +14,7 @@ inherit autotools pkgconfig lib_package
AUTO_LIBNAME_PKGS = ""
-SRC_URI =
"git://git.enlightenment.org/legacy/${BPN}.git;protocol=https;branch=master"
+SRC_URI =
"git://git.enlightenment.org/old/legacy-${BPN}.git;protocol=https;branch=master"
S = "${WORKDIR}/git"
PACKAGECONFIG ??= "jpeg png zlib ${@bb.utils.filter('DISTRO_FEATURES', 'x11',
d)}"
--
2.36.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#97143):
https://lists.openembedded.org/g/openembedded-devel/message/97143
Mute This Topic: https://lists.openembedded.org/mt/91146279/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-oe][kirkstone][PATCH] imlib2: update SRC_URI
The upstream repo location has changed, it's now
https://git.enlightenment.org/old/legacy-imlib2
It's not clear when or why it happened, but the the commit hash we use
in SRCREV exists in the 'new' location, so let's at least update the
SRC_URI for now, and fix this warning:
WARNING: imlib2-1.7.1-r0 do_fetch: Failed to fetch URL
git://git.enlightenment.org/legacy/imlib2.git;protocol=https;branch=master,
attempting MIRRORS if available
Signed-off-by: Nicolas Dechesne
Signed-off-by: Khem Raj
(cherry picked from commit 62becef1091d21f487e826df7be7dcef3ab8f94c)
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-graphics/imlib2/imlib2_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
b/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
index 56d41cd39..869f8123d 100644
--- a/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
+++ b/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
@@ -14,7 +14,7 @@ inherit autotools pkgconfig lib_package
AUTO_LIBNAME_PKGS = ""
-SRC_URI =
"git://git.enlightenment.org/legacy/${BPN}.git;protocol=https;branch=master"
+SRC_URI =
"git://git.enlightenment.org/old/legacy-${BPN}.git;protocol=https;branch=master"
S = "${WORKDIR}/git"
PACKAGECONFIG ??= "jpeg png zlib ${@bb.utils.filter('DISTRO_FEATURES', 'x11',
d)}"
--
2.36.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#97142):
https://lists.openembedded.org/g/openembedded-devel/message/97142
Mute This Topic: https://lists.openembedded.org/mt/91146236/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-oe][PATCH] imlib2: update SRC_URI
On Mon, May 16, 2022 at 6:09 PM Khem Raj wrote:
>
>
> On 5/16/22 8:28 AM, Zoltan Boszormenyi via lists.openembedded.org wrote:
> > 2022. 05. 10. 11:28 keltezéssel, Nicolas Dechesne írta:
> >> The upstream repo location has changed, it's now
> >> https://git.enlightenment.org/old/legacy-imlib2
> >
> > This hits every branch in meta-openembedded, not only master.
> >
>
> A different patch fixing same thing is already in master.
>
This is the merged patch, e.g.
62becef1091d (imlib2: update SRC_URI)
Not sure what you meant. And yes, it's needed in all branches. Do you
want/need a patch for this, or can you backport/apply directly?
>
> >>
> >> It's not clear when or why it happened, but the the commit hash we use
> >> in SRCREV exists in the 'new' location, so let's at least update the
> >> SRC_URI for now, and fix this warning:
> >>
> >> WARNING: imlib2-1.7.1-r0 do_fetch: Failed to fetch URL
> >> git://
> git.enlightenment.org/legacy/imlib2.git;protocol=https;branch=master,
> >> attempting MIRRORS if available
> >>
> >> Signed-off-by: Nicolas Dechesne
> >> ---
> >> meta-oe/recipes-graphics/imlib2/imlib2_git.bb | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
> >> b/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
> >> index 56d41cd39..869f8123d 100644
> >> --- a/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
> >> +++ b/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
> >> @@ -14,7 +14,7 @@ inherit autotools pkgconfig lib_package
> >> AUTO_LIBNAME_PKGS = ""
> >> -SRC_URI =
> >> "git://
> git.enlightenment.org/legacy/${BPN}.git;protocol=https;branch=master
> <http://git.enlightenment.org/legacy/$%7BBPN%7D.git;protocol=https;branch=master>"
>
> >>
> >> +SRC_URI =
> >> "git://
> git.enlightenment.org/old/legacy-${BPN}.git;protocol=https;branch=master
> <http://git.enlightenment.org/old/legacy-$%7BBPN%7D.git;protocol=https;branch=master>"
>
> >>
> >> S = "${WORKDIR}/git"
> >> PACKAGECONFIG ??= "jpeg png zlib
> >> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#97140):
https://lists.openembedded.org/g/openembedded-devel/message/97140
Mute This Topic: https://lists.openembedded.org/mt/91008939/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-oe][PATCH] imlib2: update SRC_URI
The upstream repo location has changed, it's now
https://git.enlightenment.org/old/legacy-imlib2
It's not clear when or why it happened, but the the commit hash we use
in SRCREV exists in the 'new' location, so let's at least update the
SRC_URI for now, and fix this warning:
WARNING: imlib2-1.7.1-r0 do_fetch: Failed to fetch URL
git://git.enlightenment.org/legacy/imlib2.git;protocol=https;branch=master,
attempting MIRRORS if available
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-graphics/imlib2/imlib2_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
b/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
index 56d41cd39..869f8123d 100644
--- a/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
+++ b/meta-oe/recipes-graphics/imlib2/imlib2_git.bb
@@ -14,7 +14,7 @@ inherit autotools pkgconfig lib_package
AUTO_LIBNAME_PKGS = ""
-SRC_URI =
"git://git.enlightenment.org/legacy/${BPN}.git;protocol=https;branch=master"
+SRC_URI =
"git://git.enlightenment.org/old/legacy-${BPN}.git;protocol=https;branch=master"
S = "${WORKDIR}/git"
PACKAGECONFIG ??= "jpeg png zlib ${@bb.utils.filter('DISTRO_FEATURES', 'x11',
d)}"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#97024):
https://lists.openembedded.org/g/openembedded-devel/message/97024
Mute This Topic: https://lists.openembedded.org/mt/91008939/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] CFP is now open for the next Yocto Project Summit 2021.11
Dear all, The next Yocto Project (virtual) Summit will take place on Nov 30 - Dec 2, 2021. While we are finalizing the registration tools, we've already opened the CFP, and we are, as always, looking for great talks and speakers ;) For more information about the event please check [1]. When you are ready to submit your presentation, go to [2]. Please as much as possible, do not reply-all since I've cross posted on several lists! If you have any questions about this event please send emails to conferen...@lists.yoctoproject.org. cheers! [1] https://yoctoproject.org/summit [2] https://pretalx.com/yocto-project-summit-2021-11/cfp -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#93175): https://lists.openembedded.org/g/openembedded-devel/message/93175 Mute This Topic: https://lists.openembedded.org/mt/85959312/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [PATCH 0/5] Various fixes for YP compatible
d'oh... I meant to add it in the prefix.. but these patches are for dunfell
branch.
On Tue, Jul 20, 2021 at 6:31 PM Nicolas Dechesne <
nicolas.deche...@linaro.org> wrote:
> There are some pending requests for YP compatible for layers which
> depend on meta-oe, meta-python and meta-networking. In dunfell, these
> layers do not PASS the yocto-check-layer compatibility script. With
> these patches applied, I am able to get this:
>
> INFO: Summary of results:
> INFO:
> INFO: meta-networking ... PASS
> INFO: meta-python ... PASS
> INFO: meta-oe ... PASS
>
> Khem Raj (1):
> libdevmapper,lvm2: Do not inherit license
>
> Nicolas Dechesne (4):
> python3-markupsafe: remove recipe
> python3-jinja2: remove recipe
> python3-{pyyaml,cython,pyparsing}: move from meta-python to meta-oe
> ostree: Do not check for meta-python
>
> .../recipes-devtools/python/python-cython.inc | 0
> .../python/python3-cython_0.29.14.bb | 0
> .../python/python3-pyparsing_2.4.6.bb | 0
> .../python/python3-pyyaml_5.3.1.bb| 0
> .../recipes-extended/ostree/ostree_2020.3.bb | 2 +-
> meta-oe/recipes-support/lvm2/lvm2.inc | 5 +--
> .../python/python3-jinja2/run-ptest | 3 --
> .../python/python3-jinja2_2.11.2.bb | 43 ---
> .../python/python3-markupsafe/run-ptest | 3 --
> .../python/python3-markupsafe_1.1.1.bb| 2 -
> 10 files changed, 3 insertions(+), 55 deletions(-)
> rename {meta-python => meta-oe}/recipes-devtools/python/python-cython.inc
> (100%)
> rename {meta-python => meta-oe}/recipes-devtools/python/
> python3-cython_0.29.14.bb (100%)
> rename {meta-python => meta-oe}/recipes-devtools/python/
> python3-pyparsing_2.4.6.bb (100%)
> rename {meta-python => meta-oe}/recipes-devtools/python/
> python3-pyyaml_5.3.1.bb (100%)
> delete mode 100644
> meta-python/recipes-devtools/python/python3-jinja2/run-ptest
> delete mode 100644 meta-python/recipes-devtools/python/
> python3-jinja2_2.11.2.bb
> delete mode 100644
> meta-python/recipes-devtools/python/python3-markupsafe/run-ptest
> delete mode 100644 meta-python/recipes-devtools/python/
> python3-markupsafe_1.1.1.bb
>
> --
> 2.29.2
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#92284):
https://lists.openembedded.org/g/openembedded-devel/message/92284
Mute This Topic: https://lists.openembedded.org/mt/84336619/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-oe][PATCH] sysbench: upgrade to 1.0.20
On Wed, May 19, 2021 at 6:37 PM Khem Raj wrote:
> seeing this failure
>
> https://errors.yoctoproject.org/Errors/Details/584952/
hmm. Sorry about the delay.. Looks like I am not able to reproduce the
error, it builds for me with oe-core only and with:
Build Configuration:
BB_VERSION = "1.51.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING = "debian-10"
TARGET_SYS = "arm-oe-linux-gnueabi"
MACHINE = "qemuarm"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES= "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU = "hard"
Do you have any idea why it would work for me, and not for you?
>
>
> On Tue, May 18, 2021 at 11:01 PM Nicolas Dechesne
> wrote:
> >
> > * Upstream moved to Github, let's use it for SRC_URI
> > * COPYING file was changed, but with no impact on license
> > * sysbench includes a copy of luajit project and it's compiled by
> > default. However the internal copy of luajit won't cross compile
> > properly, without patching it (it uses 'gcc'). So instead use the
> > 'system' luajit, e.g. the one package from OE (which is what most
> > distro do anyways)
> > * Does not compile with different built folder. Lua generated files
> > have things like that:
> > unsigned char
> __/__/__/__/sysbench-1_0_20/src/lua/internal/sysbench_lua[] =
> >
> > Signed-off-by: Nicolas Dechesne
> > ---
> > ...{sysbench_0.4.12.bb => sysbench_1.0.20.bb} | 21 ---
> > 1 file changed, 14 insertions(+), 7 deletions(-)
> > rename meta-oe/recipes-benchmark/sysbench/{sysbench_0.4.12.bb =>
> sysbench_1.0.20.bb} (56%)
> >
> > diff --git a/meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
> b/meta-oe/recipes-benchmark/sysbench/sysbench_1.0.20.bb
> > similarity index 56%
> > rename from meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
> > rename to meta-oe/recipes-benchmark/sysbench/sysbench_1.0.20.bb
> > index 708c71f4f..555477ab0 100644
> > --- a/meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
> > +++ b/meta-oe/recipes-benchmark/sysbench/sysbench_1.0.20.bb
> > @@ -2,16 +2,17 @@ SUMMARY = "System performance benchmark"
> > HOMEPAGE = "http://github.com/akopytov/sysbench";
> > SECTION = "console/tests"
> > LICENSE = "GPLv2"
> > -LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
> > +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> >
> > -inherit autotools
> > +DEPENDS = "luajit"
> >
> > -# The project has moved from Sourceforge to Launchpad, to Github. Use
> the source tarball from
> > -# Launchpad until the next release is available from Github.
> > -SRC_URI = "
> https://launchpad.net/ubuntu/+archive/primary/+files/${BPN}_${PV}.orig.tar.gz
> <https://launchpad.net/ubuntu/+archive/primary/+files/$%7BBPN%7D_$%7BPV%7D.orig.tar.gz>
> "
> > +inherit autotools pkgconfig
> >
> > -SRC_URI[md5sum] = "3a6d54fdd3fe002328e4458206392b9d"
> > -SRC_URI[sha256sum] =
> "83fa7464193e012c91254e595a89894d8e35b4a38324b52a5974777e3823ea9e"
> > +SRC_URI = "git://github.com/akopytov/${BPN}.git
> <http://github.com/akopytov/$%7BBPN%7D.git>"
> > +
> > +SRCREV = "ebf1c90da05dea94648165e4f149abc20c979557"
> > +
> > +S = "${WORKDIR}/git"
> >
> > PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'largefile',
> d)}"
> > PACKAGECONFIG[largefile] = "--enable-largefile,--disable-largefile,,"
> > @@ -21,6 +22,12 @@ PACKAGECONFIG[mysql] = "--with-mysql \
> > --with-mysql-libs=${STAGING_LIBDIR}, \
> > --without-mysql,mysql5"
> >
> > +# the internal luajit won't cross compile
> > +EXTRA_OECONF += "--with-system-luajit"
> > +
> > +# lua.h generated files are bogus when using B != S
> > +B = "${S}"
> > +
> > do_configure_prepend() {
> > touch ${S}/NEWS ${S}/AUTHORS
> > }
> > --
> > 2.29.2
> >
> >
> >
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#91503):
https://lists.openembedded.org/g/openembedded-devel/message/91503
Mute This Topic: https://lists.openembedded.org/mt/82930246/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-oe] [PATCH] gpsd: fix build on aarch64
On Fri, May 15, 2020 at 2:14 PM Sean Nyekjaer wrote:
> Explicitly add ${CC} as linker, for it to understand -Wl option.
>
> Signed-off-by: Sean Nyekjaer
> ---
>
> Alistair please check in your setup :)
>
I had found the same error on dragonboard/arm64. This patch fixes the build
problem. Note that I have only done build test, not run time.
thanks!
>
> meta-oe/recipes-navigation/gpsd/gpsd_3.20.bb | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta-oe/recipes-navigation/gpsd/gpsd_3.20.bb
> b/meta-oe/recipes-navigation/gpsd/gpsd_3.20.bb
> index 0914f7ec2..5463c8231 100644
> --- a/meta-oe/recipes-navigation/gpsd/gpsd_3.20.bb
> +++ b/meta-oe/recipes-navigation/gpsd/gpsd_3.20.bb
> @@ -35,6 +35,7 @@ EXTRA_OESCONS = " \
> systemd='${SYSTEMD_OESCONS}' \
> libdir='${libdir}' \
> manbuild='false' \
> +LINK='${CC}' \
> ${PACKAGECONFIG_CONFARGS} \
> "
> # this cannot be used, because then chrpath is not found and only static
> lib is built
> @@ -44,6 +45,7 @@ do_compile_prepend() {
> export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}"
> export
> PKG_CONFIG="PKG_CONFIG_SYSROOT_DIR=\"${PKG_CONFIG_SYSROOT_DIR}\" pkg-config"
> export STAGING_PREFIX="${STAGING_DIR_HOST}/${prefix}"
> +export LD="${CC}"
> export LINKFLAGS="${LDFLAGS}"
> }
>
> @@ -51,6 +53,7 @@ do_install() {
> export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}"
> export
> PKG_CONFIG="PKG_CONFIG_SYSROOT_DIR=\"${PKG_CONFIG_SYSROOT_DIR}\" pkg-config"
> export STAGING_PREFIX="${STAGING_DIR_HOST}/${prefix}"
> +export LD="${CC}"
> export LINKFLAGS="${LDFLAGS}"
>
> export DESTDIR="${D}"
> --
> 2.26.2
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#84361):
https://lists.openembedded.org/g/openembedded-devel/message/84361
Mute This Topic: https://lists.openembedded.org/mt/74225704/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] Community stats dashboard
hi there, we have put in place a dashboard that shows our community engagement and stats. We are using a service from Bitergia for that, and they are using open source tools from the LF CHAOSS project [1]. The dashboard is publicly available at [2]. Feel free to have a look at the data, the tool is doing its best to map users' identities (email, git, bugzilla, ...). It also tries to map when possible users with their respective company/employer, so that gives everyone a map of who contributes and participate to the project. If you have any questions or issues with the tool, please let me know. If any mailing list or git tree is missing and you would like it to be added, let me know and I will do it. If you want to update your data on the dashboard such as typo, or if you want to show (or update, or hide) your employer affiliation, or if you want to anonymise your data on the public dashboard, please reach out to me as well. cheers nicolas [1] https://chaoss.community/ [2] https://yoctoproject.biterg.io -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#83456): https://lists.openembedded.org/g/openembedded-devel/message/83456 Mute This Topic: https://lists.openembedded.org/mt/72489657/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-ota][PATCH] meta-ota: add support for binary-delta images in a new layer
hi Bartosz, On Wed, Mar 11, 2020 at 9:04 AM Bartosz Golaszewski wrote: > wt., 3 mar 2020 o 14:56 Bartosz Golaszewski napisał(a): > > > > If this is not something that should be part of meta-openembedded - is > > there any way to have it hosted at https://git.yoctoproject.org/cgit/ > > as an official yocto layer? I'm sorry if this is a dumb question, I > > don't know exactly what the policy is for that. > > > > Hi Khem, > > gentle ping on this. What is the procedure of hosting a layer at OE? > it depends what you mean here. 1. Hosting on git.yoctoproject.org is mostly for layers supported by YP membership, these layers are under the responsibility of the YP TSC [1] 2. Hosting on git.openembedded.org is under the responsibility of the OE TSC [2] We recently started an initiative using gitlab, to host layers: https://gitlab.com/openembedded/community, though it's not picking up much for now. But that would be another option, Paul B. or myself could give you access You might want to host the layer on your own (github, gitlab or anywhere else). I understand why you think that hosting on yoctoproject.org would make it 'more' official, however hundreds of layers are 'self hosted' and it's usually not a big concern. In any case you should register your layer in the OE layer index. [1] https://wiki.yoctoproject.org/wiki/TSC [2] https://www.openembedded.org/wiki/TSC > Bartosz > -- > ___ > 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] Demos for the Yocto Project booth at ELCE in Lyon
Dear all, As usual, the Yocto Project will have a booth at the ELCE conference in Lyon later this month. While the booth is a great opportunity for everyone to get a new sticker of your favorite project ;-) we are also very excited when developers from our community get a chance to show off the fun and cool things they build thanks to the Yocto Project! If you want to bring any of your cool demo on the YP booth, please reply to Andreea (cc'd) and I so that we can plan and discuss any of the logistics! Also, don't forget that right after ELCE we are having our first Yocto Project Summit, with a very exciting schedule and great set of speakers. If you haven't done so already, please check out: https://www.yoctoproject.org/yocto-project-summit-2019/ cheers nico -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Yocto Project Summit at ELCE Call for Particpation
hi Philip, thanks for sending this out! On Mon, Aug 19, 2019 at 3:17 AM Philip Balister wrote: > > At the past few OopenEmbedded developer meetings, people have been > asking for more developer and user focused events like a miniconf. > Partly based on this feedback, there is a two day event sponsored by the > Yocto Project that provides a chance for people to talk about the Yocto > Project and OpenEmbedded. The CFP is a bit buried on the page and I like > to get it more exposure, so here the direct link: all information about the Summit is also available here now: https://wiki.yoctoproject.org/wiki/Yocto_Project_Summit_2019 > > https://events.linuxfoundation.org/wp-content/uploads/2019/08/Yocto-Project-Summit-2019-CFP-1.pdf > > We'd like to see new faces talking. We know there are a lot of good > stories out there, that will help lots of people become better users and > developers. > > The link to the event is here: > > https://events.linuxfoundation.org/events/embedded-linux-conference-europe-2019/program/co-located-events/ > > Follow the path to the Yocto Project Summit. If you are alrady signed up > for ELCE, you should be able to update your registration to include the > Summit. > > Philip > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] cannelloni: move from meta-oe to meta-networking
It has a dependency on lksctp-tools which is available in
meta-networking. Move the recipe to avoid dependency from meta-oe onto
meta-networking.
Signed-off-by: Nicolas Dechesne
---
.../recipes-connectivity/cannelloni/cannelloni_git.bb | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename {meta-oe =>
meta-networking}/recipes-connectivity/cannelloni/cannelloni_git.bb (100%)
diff --git a/meta-oe/recipes-connectivity/cannelloni/cannelloni_git.bb
b/meta-networking/recipes-connectivity/cannelloni/cannelloni_git.bb
similarity index 100%
rename from meta-oe/recipes-connectivity/cannelloni/cannelloni_git.bb
rename to meta-networking/recipes-connectivity/cannelloni/cannelloni_git.bb
--
2.20.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][warrior][thud][PATCH] cpupower: remove LIC_FILES_CHKSUM
cpupower is a 'special' recipe since it does "inherit kernelsrc" , which essentially means that it doesn't have its own sources, but reuse the kernel source tree, from virtual/kernel recipe. As such, checking the license file in cpupower recipe does not seem relevant, since it does not fetch anything (kernelsrc has "deltask do_fetch") and the fetching is deferred to the virtual/kernel recipe. so we are basically checking the COPYING file twice. If there was any license issue, it would have been caught by virtual/kernel recipe already. Hence we remove LIC_FILES_CHKSUM like it is done for perf recipe in OE-core in meta/recipes-kernel/perf/perf.bb. It has the nice side effect that BSP layers can use different kernel versions without worrying about any LICENSE checksum changes in between kernel versions. Reported-by: Daniel Díaz Signed-off-by: Nicolas Dechesne Signed-off-by: Khem Raj (cherry picked from commit 7142f09407b81c2221bbf1c5078641ab4bc63ee9) --- Armin, for our use cases (at least) this is a bug fix, since we use different kernel versions in our BSP layers.. I am hoping you will agree to merge it is -stable branches. If you can apply to warrior and thud where it applies cleanly that would be really nice. It won't apply on sumo, i can send another patch later for sumo. --- meta-oe/recipes-kernel/cpupower/cpupower.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta-oe/recipes-kernel/cpupower/cpupower.bb b/meta-oe/recipes-kernel/cpupower/cpupower.bb index 928973871..abf1585de 100644 --- a/meta-oe/recipes-kernel/cpupower/cpupower.bb +++ b/meta-oe/recipes-kernel/cpupower/cpupower.bb @@ -2,7 +2,6 @@ SUMMARY = "Shows and sets processor power related values" DESCRIPTION = "cpupower is a collection of tools to examine and tune power \ saving related features of your processor." LICENSE = "GPLv2" -LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" DEPENDS = "pciutils gettext-native" PROVIDES = "virtual/cpupower" -- 2.20.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH v2] cannelloni: new package, CAN to ethernet proxy
On Fri, May 10, 2019 at 6:49 PM Sean Nyekjær wrote:
>
>
>
> > On 10 May 2019, at 15.08, Nicolas Dechesne
> > wrote:
> >
> > On Tue, Apr 30, 2019 at 8:09 AM Sean Nyekjaer via Openembedded-devel
> > wrote:
> >>
> >> Tool for sending SocketCAN messages
> >> over Ethernet tunnel.
> >>
> >> Signed-off-by: Sean Nyekjaer
> >> ---
> >> Changes in v2:
> >> - Added PV
> >>
> >> .../cannelloni/cannelloni_git.bb| 17 +
> >> 1 file changed, 17 insertions(+)
> >> create mode 100644
> >> meta-oe/recipes-connectivity/cannelloni/cannelloni_git.bb
> >>
> >> diff --git a/meta-oe/recipes-connectivity/cannelloni/cannelloni_git.bb
> >> b/meta-oe/recipes-connectivity/cannelloni/cannelloni_git.bb
> >> new file mode 100644
> >> index 0..df75e6342
> >> --- /dev/null
> >> +++ b/meta-oe/recipes-connectivity/cannelloni/cannelloni_git.bb
> >> @@ -0,0 +1,17 @@
> >> +SUMMARY = "a SocketCAN over Ethernet tunnel"
> >> +HOMEPAGE = "https://github.com/mguentner/cannelloni";
> >> +LICENSE = "GPLv2"
> >> +
> >> +SRC_URI = "git://github.com/mguentner/cannelloni.git;protocol=https"
> >> +SRCREV = "44080bb021d1a143e6906f2ec4610513c4e1cece"
> >> +
> >> +PV = "20160414+${SRCPV}"
> >> +
> >> +LIC_FILES_CHKSUM =
> >> "file://gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> >> +
> >> +inherit cmake
> >> +
> >> +S = "${WORKDIR}/git"
> >> +
> >> +PACKAGECONFIG ??= "lksctp-tools"
> >> +PACKAGECONFIG[lksctp-tools] = "-DSCTP_SUPPORT=true, -DSCTP_SUPPORT=false,
> >> lksctp-tools"
> >
> > lksctp-tools recipe is in meta-networking, so we've added an implicit
> > dependency on meta-networking by taking this patch. should we disable
> > lksctp-tools support by default?
> I completely missed that. :-D
> It seems to be the correct solution, to disable it by default...
> Will you send a patch?
I would prefer the other solution Khem proposed, and move it to
meta-networking.. what do you think?
>
> /Sean
> >
> >> --
> >> 2.21.0
> >>
> >> --
> >> ___
> >> 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
Re: [oe] [PATCH v2] cannelloni: new package, CAN to ethernet proxy
On Tue, Apr 30, 2019 at 8:09 AM Sean Nyekjaer via Openembedded-devel
wrote:
>
> Tool for sending SocketCAN messages
> over Ethernet tunnel.
>
> Signed-off-by: Sean Nyekjaer
> ---
> Changes in v2:
> - Added PV
>
> .../cannelloni/cannelloni_git.bb| 17 +
> 1 file changed, 17 insertions(+)
> create mode 100644 meta-oe/recipes-connectivity/cannelloni/cannelloni_git.bb
>
> diff --git a/meta-oe/recipes-connectivity/cannelloni/cannelloni_git.bb
> b/meta-oe/recipes-connectivity/cannelloni/cannelloni_git.bb
> new file mode 100644
> index 0..df75e6342
> --- /dev/null
> +++ b/meta-oe/recipes-connectivity/cannelloni/cannelloni_git.bb
> @@ -0,0 +1,17 @@
> +SUMMARY = "a SocketCAN over Ethernet tunnel"
> +HOMEPAGE = "https://github.com/mguentner/cannelloni";
> +LICENSE = "GPLv2"
> +
> +SRC_URI = "git://github.com/mguentner/cannelloni.git;protocol=https"
> +SRCREV = "44080bb021d1a143e6906f2ec4610513c4e1cece"
> +
> +PV = "20160414+${SRCPV}"
> +
> +LIC_FILES_CHKSUM = "file://gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> +
> +inherit cmake
> +
> +S = "${WORKDIR}/git"
> +
> +PACKAGECONFIG ??= "lksctp-tools"
> +PACKAGECONFIG[lksctp-tools] = "-DSCTP_SUPPORT=true, -DSCTP_SUPPORT=false,
> lksctp-tools"
lksctp-tools recipe is in meta-networking, so we've added an implicit
dependency on meta-networking by taking this patch. should we disable
lksctp-tools support by default?
> --
> 2.21.0
>
> --
> ___
> 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] bpftool: remove LIC_FILES_CHKSUM
bpftool is a 'special' recipe since it does "inherit kernelsrc", like
perf in oe-core or cpupower in meta-oe.
they don't have their own sources, but reuse the kernel source tree,
from virtual/kernel recipe. As such, checking the license file does
not seem relevant, since the fetching (and license check) is deferred
to the virtual/kernel recipe.
Remove LIC_FILES_CHKSUM like it is done in perf and cpupower.
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-kernel/bpftool/bpftool.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta-oe/recipes-kernel/bpftool/bpftool.bb
b/meta-oe/recipes-kernel/bpftool/bpftool.bb
index f75ac6f81..39c478a95 100644
--- a/meta-oe/recipes-kernel/bpftool/bpftool.bb
+++ b/meta-oe/recipes-kernel/bpftool/bpftool.bb
@@ -2,7 +2,6 @@ SUMMARY = "Inspect and manipulate eBPF programs and maps"
DESCRIPTION = "bpftool is a kernel tool for inspection and simple manipulation
\
of eBPF programs and maps."
LICENSE = "GPLv2"
-LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
DEPENDS = "binutils elfutils"
PROVIDES = "virtual/bpftool"
--
2.20.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] cpupower: remove LIC_FILES_CHKSUM
cpupower is a 'special' recipe since it does "inherit kernelsrc" , which essentially means that it doesn't have its own sources, but reuse the kernel source tree, from virtual/kernel recipe. As such, checking the license file in cpupower recipe does not seem relevant, since it does not fetch anything (kernelsrc has "deltask do_fetch") and the fetching is deferred to the virtual/kernel recipe. so we are basically checking the COPYING file twice. If there was any license issue, it would have been caught by virtual/kernel recipe already. Hence we remove LIC_FILES_CHKSUM like it is done for perf recipe in OE-core in meta/recipes-kernel/perf/perf.bb. It has the nice side effect that BSP layers can use different kernel versions without worrying about any LICENSE checksum changes in between kernel versions. Reported-by: Daniel Díaz Signed-off-by: Nicolas Dechesne --- meta-oe/recipes-kernel/cpupower/cpupower.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta-oe/recipes-kernel/cpupower/cpupower.bb b/meta-oe/recipes-kernel/cpupower/cpupower.bb index 5798440e9..cf70eb2c8 100644 --- a/meta-oe/recipes-kernel/cpupower/cpupower.bb +++ b/meta-oe/recipes-kernel/cpupower/cpupower.bb @@ -2,7 +2,6 @@ SUMMARY = "Shows and sets processor power related values" DESCRIPTION = "cpupower is a collection of tools to examine and tune power \ saving related features of your processor." LICENSE = "GPLv2" -LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" DEPENDS = "pciutils gettext-native" PROVIDES = "virtual/cpupower" -- 2.20.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] cpupower: update license file checksum
hey,
On Mon, Apr 22, 2019 at 10:38 PM Daniel Díaz wrote:
>
> Hello!
>
> On Mon, 22 Apr 2019 at 15:15, Martin Jansa wrote:
> > NAK
> >
> > This completely defeats the purpose of LIC_FILES_CHKSUM.
> > If the COPYING file vary across releases than LIC_FILES_CHKSUM should be
> > updated when needed while verifying that the LICENSE value is still correct.
> > If you use COMMON_LICENSE_DIR and completely ignore the license in the
> > source, then it won't ever warn the user that the license was changed while
> > upgrading to newer release.
I hit this issue today as well.. so looked into it..
>
>
> I understand the sentiment and agree to the principle. Besides,
> licensing of the kernel source code does not change too often -- Last
> change in the kernel was over a year ago, and it was not relicensed,
> just reshuffled.
>
> This does, however, blocks us from switching kernels or building
> different versions with the same OE baseline. Our [1] main targets are
> Linux LTS's: 4.4, 4.9, 4.14, 4.19, and (currently) 5.0; we also build
> Linux mainline and Linux next. For automated bisections or for a
> kernel developer tree, we have to rely on the given kernel source
> code, which might contain any license that cpupower has had in the
> past. We know for sure that _that_ is GPL-2, but we can't adjust the
> checksum on the fly.
>
> We're fine carrying this patch in our trees, as we can burden
> ourselves with looking at licensing of the kernel, but because this
> was so promptly NAKed, I also very much would like to hear feedback on
> how to deal with such limitation in a way that could be acceptable in
> meta-oe.
cpupower is a 'special' recipe since it does "inherit kernelsrc" ,
which essentially means that it doesn't have its own sources, but
reuse the kernel source tree, from virtual/kernel recipe. As such,
checking the license file in cpupower recipe does not seem relevant,
since it does not fetch anything (kernelsrc has "deltask do_fetch")
and the fetching is deferred to the virtual/kernel recipe.
so we are basically checking the COPYING file twice. If there was any
license issue, it would have been caught by virtual/kernel recipe
already.
so the proposed patch doesn't seem too bad.. in fact, we might even
want to do that directly in kernelsrc.bbclass.
well, in fact.. i now just checked at other recipes that uses
kernelsrc and found that:
* meta/recipes-kernel/perf/perf.bb: does not set LIC_FILES_CHKSUMS,
and it works fine...
* meta-oe/recipes-kernel/bpftool/bpftool.bb: it has this:
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
Since we remove do_fetch task explicitly , i think that removing
LIC_FILES_CHKSUMS (like in perf.bb) should be the best approach. I
tried to build cpupower without LIC_FILES_CHKSUMS and it worked..
>
> Thanks and greetings!
>
> Daniel Díaz
> daniel.d...@linaro.org
>
>
> [1] https://lkft.linaro.org/about/
>
>
> > On Mon, Apr 22, 2019 at 10:09 PM Daniel Díaz wrote:
> >>
> >> The Linux kernel is GPLv2, at least as far cpupower is
> >> concerned. Because this recipe reuses the kernel code, and
> >> said source code can (does) vary across different releases,
> >> it's best to refer to license by its name.
> >>
> >> Use GPL-2.0 from OE common license dir.
> >>
> >> Signed-off-by: Daniel Díaz
> >> ---
> >> meta-oe/recipes-kernel/cpupower/cpupower.bb | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta-oe/recipes-kernel/cpupower/cpupower.bb
> >> b/meta-oe/recipes-kernel/cpupower/cpupower.bb
> >> index 928973871..c7ea087a5 100644
> >> --- a/meta-oe/recipes-kernel/cpupower/cpupower.bb
> >> +++ b/meta-oe/recipes-kernel/cpupower/cpupower.bb
> >> @@ -2,7 +2,7 @@ SUMMARY = "Shows and sets processor power related values"
> >> DESCRIPTION = "cpupower is a collection of tools to examine and tune
> >> power \
> >> saving related features of your processor."
> >> LICENSE = "GPLv2"
> >> -LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
> >> +LIC_FILES_CHKSUM =
> >> "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
> >> DEPENDS = "pciutils gettext-native"
> >> PROVIDES = "virtual/cpupower"
> >>
> >> --
> >> 2.17.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
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 0/4] A few fixes when trying to run yocto-check-layer
On Fri, Feb 22, 2019 at 7:14 PM Khem Raj wrote: > > On Fri, Feb 22, 2019 at 9:30 AM Nicolas Dechesne > wrote: > > > > I was trying to run yocto-check-layer script and it has caught some issues. > > > > Note that I was able to get a PASS status for meta-oe, using two additional > > patches > > from Mingli Yu , i found on the list: > > > > upower: add REQUIRED_DISTRO_FEATURES for polkit > > udisks2: add REQUIRED_DISTRO_FEATURES for polkit > > > > they are in master-next right. that's actually where I took them. Just wanted to highlight that with these 2 patches + my 4 patches, the script passes. > > > Nicolas Dechesne (4): > > meta-oe: fixup LAYERDEPENDS to include meta-python > > polkit: add REQUIRED_DISTRO_FEATURES for polkit > > packagegroup-meta-oe: fixup package that now require polkit > > udisks: add REQUIRED_DISTRO_FEATURES for polkit > > > > meta-oe/conf/layer.conf| 1 + > > meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb | 3 ++- > > meta-oe/recipes-extended/polkit/polkit-group-rule.inc | 3 +++ > > meta-oe/recipes-support/udisks/udisks_1.0.5.bb | 5 - > > 4 files changed, 10 insertions(+), 2 deletions(-) > > > > -- > > 2.20.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 2/4] polkit: add REQUIRED_DISTRO_FEATURES for polkit
After below commits to add polkit as a required
distro feature:
97a1a55 polkit: add polkit as a required distro feature
c049e02 polkit: inherit distro_features_check
All recipes that includes polkit-group-rule.inc will fail to parse
when polkit is not in DISTRO_FEATURE, especially 'world'. e.g.
ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.
Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'udisks',
'polkit']
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-extended/polkit/polkit-group-rule.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta-oe/recipes-extended/polkit/polkit-group-rule.inc
b/meta-oe/recipes-extended/polkit/polkit-group-rule.inc
index 40e4005423..06ab106420 100644
--- a/meta-oe/recipes-extended/polkit/polkit-group-rule.inc
+++ b/meta-oe/recipes-extended/polkit/polkit-group-rule.inc
@@ -1,6 +1,9 @@
# polkit must prepare polkitd group
DEPENDS += "polkit"
+inherit distro_features_check
+REQUIRED_DISTRO_FEATURES = "polkit"
+
inherit useradd
do_install_prepend() {
--
2.20.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH 4/4] udisks: add REQUIRED_DISTRO_FEATURES for polkit
After below commits to add polkit as a required distro feature:
97a1a55 polkit: add polkit as a required distro feature
c049e02 polkit: inherit distro_features_check
Need to add REQUIRED_DISTRO_FEATURES for polkit to avoid error when
trying to build 'world'
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-support/udisks/udisks_1.0.5.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-support/udisks/udisks_1.0.5.bb
b/meta-oe/recipes-support/udisks/udisks_1.0.5.bb
index 7cd9992214..3ae8ecc15c 100644
--- a/meta-oe/recipes-support/udisks/udisks_1.0.5.bb
+++ b/meta-oe/recipes-support/udisks/udisks_1.0.5.bb
@@ -22,7 +22,10 @@ SRC_URI =
"http://hal.freedesktop.org/releases/${BPN}-${PV}.tar.gz;name=${BPN} \
SRC_URI[udisks.md5sum] = "70d48dcfe523a74cd7c7fbbc2847fcdd"
SRC_URI[udisks.sha256sum] =
"f2ec82eb0ea7e01dc299b5b29b3c18cdf861236ec43dcff66b3552b4b31c6f71"
-inherit autotools-brokensep systemd gtk-doc
+inherit autotools-brokensep systemd gtk-doc distro_features_check
+
+REQUIRED_DISTRO_FEATURES = "polkit"
+
PACKAGECONFIG ??= "libdevmapper"
PACKAGECONFIG[libdevmapper] =
"--enable-devmapper,--disable-devmapper,libdevmapper"
--
2.20.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH 3/4] packagegroup-meta-oe: fixup package that now require polkit
After below commits to add polkit as a required distro feature:
97a1a55 polkit: add polkit as a required distro feature
c049e02 polkit: inherit distro_features_check
We need to propagate that to all recipes that use/need them, such as
this packagegroup, otherwise 'world' will fail.
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
index 96672db9a0..5fcf9899b6 100644
--- a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
+++ b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
@@ -243,7 +243,7 @@ RDEPENDS_packagegroup-meta-oe-support ="\
sjf2410-linux-native satyr sdparm pty-forward-native serial-forward \
sg3-utils sharutils smem spitools srecord ssiapi start-stop-daemon
stm32flash \
syslog-ng system-config-keyboard tbb thin-provisioning-tools tokyocabinet \
-tree udisks udisks2 uhubctl unixodbc upower uriparser usb-modeswitch \
+tree uhubctl unixodbc uriparser usb-modeswitch \
usb-modeswitch-data usbpath uthash utouch-evemu utouch-frame \
vim vim-tiny websocketpp wmiconfig xdelta3 xdg-user-dirs xmlstarlet \
zbar zile \
@@ -251,6 +251,7 @@ RDEPENDS_packagegroup-meta-oe-support ="\
${@bb.utils.contains("DISTRO_FEATURES", "pulseadio bluez4", "libcanberra",
"", d)} \
${@bb.utils.contains("DISTRO_FEATURES", "x11 pam", "xorgxrdp xrdp", "",
d)} \
${@bb.utils.contains("DISTRO_FEATURES", "bluez4", "procmail", "", d)} \
+${@bb.utils.contains("DISTRO_FEATURES", "polkit", "udisks udisks2 upower",
"", d)} \
${NE10} \
"
--
2.20.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH 1/4] meta-oe: fixup LAYERDEPENDS to include meta-python
meta-oe depends on meta-python, for mongodb recipe, since 5cf9a144ad16 (mongodb: Upgrade to 4.0.1 release) Trying to run the yocto-check-layer script fails with: ERROR: Nothing PROVIDES 'python-cheetah-native' (but /work/yocto/meta-openembedded/meta-oe/recipes-dbs/mongodb/mongodb_git.bb DEPENDS on or otherwise requires it). Close matches: python3-git-native python-nose-native python-native ERROR: Required build target 'meta-world-pkgdata' has no buildable providers. Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'mongodb', 'python-cheetah-native'] Signed-off-by: Nicolas Dechesne --- meta-oe/conf/layer.conf | 1 + 1 file changed, 1 insertion(+) diff --git a/meta-oe/conf/layer.conf b/meta-oe/conf/layer.conf index 23c10ce339..8cedcf0d0b 100644 --- a/meta-oe/conf/layer.conf +++ b/meta-oe/conf/layer.conf @@ -28,6 +28,7 @@ BBFILE_PRIORITY_openembedded-layer = "6" LAYERVERSION_openembedded-layer = "1" LAYERDEPENDS_openembedded-layer = "core" +LAYERDEPENDS_openembedded-layer = "meta-python" LAYERSERIES_COMPAT_openembedded-layer = "thud" -- 2.20.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH 0/4] A few fixes when trying to run yocto-check-layer
I was trying to run yocto-check-layer script and it has caught some issues. Note that I was able to get a PASS status for meta-oe, using two additional patches from Mingli Yu , i found on the list: upower: add REQUIRED_DISTRO_FEATURES for polkit udisks2: add REQUIRED_DISTRO_FEATURES for polkit Nicolas Dechesne (4): meta-oe: fixup LAYERDEPENDS to include meta-python polkit: add REQUIRED_DISTRO_FEATURES for polkit packagegroup-meta-oe: fixup package that now require polkit udisks: add REQUIRED_DISTRO_FEATURES for polkit meta-oe/conf/layer.conf| 1 + meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb | 3 ++- meta-oe/recipes-extended/polkit/polkit-group-rule.inc | 3 +++ meta-oe/recipes-support/udisks/udisks_1.0.5.bb | 5 - 4 files changed, 10 insertions(+), 2 deletions(-) -- 2.20.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][thud][PATCH] packagegroup-meta-oe: drop ptest packages that do not exist
On Tue, Feb 19, 2019 at 4:13 PM akuster808 wrote: > > > > On 2/19/19 6:28 AM, Nicolas Dechesne wrote: > > On Tue, Feb 19, 2019 at 2:50 PM Nicolas Dechesne > > wrote: > >> From: Alexander Kanavin > >> > >> Signed-off-by: Alexander Kanavin > >> Signed-off-by: Khem Raj > >> (cherry picked from commit bbde0a3d3012da1d6be824959b0ad0a930573650) > >> Signed-off-by: Nicolas Dechesne > >> --- > >> meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb | 4 > >> 1 file changed, 4 deletions(-) > > please ignore for now. I need to backport more than this one, > > actually. i will send a series instead. > > are they in stable/thud-next ? > > https://git.openembedded.org/meta-openembedded-contrib/log/?h=stable/thud-next nice! they all are ;) looking forward to the update in thud then! > > > >> diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb > >> b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb > >> index 08b4bbfc4..2a23a6170 100644 > >> --- a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb > >> +++ b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb > >> @@ -234,19 +234,15 @@ RDEPENDS_packagegroup-meta-oe-test ="\ > >> > >> RDEPENDS_packagegroup-meta-oe-ptest = "\ > >> zeromq-ptest \ > >> -libxml-ptest \ > >> -soci-ptest \ > >> leveldb-ptest \ > >> psqlodbc-ptest \ > >> lua-ptest \ > >> protobuf-ptest \ > >> -libdbi-ptest \ > >> rsyslog-ptest \ > >> oprofile-ptest \ > >> libteam-ptest \ > >> uthash-ptest \ > >> mcelog-ptest \ > >> -openldap-ptest \ > >> libee-ptest \ > >> numactl-ptest \ > >> poco-ptest \ > >> -- > >> 2.20.1 > >> > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][thud][PATCH] packagegroup-meta-oe: drop ptest packages that do not exist
On Tue, Feb 19, 2019 at 2:50 PM Nicolas Dechesne wrote: > > From: Alexander Kanavin > > Signed-off-by: Alexander Kanavin > Signed-off-by: Khem Raj > (cherry picked from commit bbde0a3d3012da1d6be824959b0ad0a930573650) > Signed-off-by: Nicolas Dechesne > --- > meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb | 4 > 1 file changed, 4 deletions(-) please ignore for now. I need to backport more than this one, actually. i will send a series instead. > > diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb > b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb > index 08b4bbfc4..2a23a6170 100644 > --- a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb > +++ b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb > @@ -234,19 +234,15 @@ RDEPENDS_packagegroup-meta-oe-test ="\ > > RDEPENDS_packagegroup-meta-oe-ptest = "\ > zeromq-ptest \ > -libxml-ptest \ > -soci-ptest \ > leveldb-ptest \ > psqlodbc-ptest \ > lua-ptest \ > protobuf-ptest \ > -libdbi-ptest \ > rsyslog-ptest \ > oprofile-ptest \ > libteam-ptest \ > uthash-ptest \ > mcelog-ptest \ > -openldap-ptest \ > libee-ptest \ > numactl-ptest \ > poco-ptest \ > -- > 2.20.1 > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][thud][PATCH] packagegroup-meta-oe: drop ptest packages that do not exist
From: Alexander Kanavin Signed-off-by: Alexander Kanavin Signed-off-by: Khem Raj (cherry picked from commit bbde0a3d3012da1d6be824959b0ad0a930573650) Signed-off-by: Nicolas Dechesne --- meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb | 4 1 file changed, 4 deletions(-) diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb index 08b4bbfc4..2a23a6170 100644 --- a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb +++ b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb @@ -234,19 +234,15 @@ RDEPENDS_packagegroup-meta-oe-test ="\ RDEPENDS_packagegroup-meta-oe-ptest = "\ zeromq-ptest \ -libxml-ptest \ -soci-ptest \ leveldb-ptest \ psqlodbc-ptest \ lua-ptest \ protobuf-ptest \ -libdbi-ptest \ rsyslog-ptest \ oprofile-ptest \ libteam-ptest \ uthash-ptest \ mcelog-ptest \ -openldap-ptest \ libee-ptest \ numactl-ptest \ poco-ptest \ -- 2.20.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [yocto] layers.openembedded.org upgraded
On Thu, Sep 27, 2018 at 10:43 PM Paul Eggleton wrote: > > Hi all, > > I'm very happy to announce that we've finally been able to upgrade the layer > index at http://layers.openembedded.org to the latest revision on master, > incorporating quite a bit of work that's been going on for the past few > months. Improvements now visible: > > * Patch tracking - each recipe detail page now lists any patches being applied > by the recipe along with upstream status for each - see attached screenshot. > You can click through to view/download the actual patch, and any URLs in the > supplemental status text are also made into clickable links. > > * Source tracking - remote entries in SRC_URI are now listed on the recipe > detail page and made into clickable links where possible - see attached > screenshot > > * Link to inc files - there is now a link in the recipe detail page to any inc > files that a recipe includes as long as they are in the same directory, as a > shortcut to see the rest of the definitions for the recipe. > > * Recipe list CSV export - there is now an "Export CSV" button at the top of > the recipe list on the layer detail page. This currently includes the recipe > name and version - we could look at extending this, but note that the REST API > provides access to all of the information programmatically and may be better > suited for many applications that need this data. > > * Site-wide notice support - admins can now add notifications to appear at the > top of the page across the entire site. This is useful in the case where there > is some problem with the update process or maintenance is going on as happens > from time to time. > > * Bootstrap 3 - the UI has been updated to use Bootstrap 3 from version 2 that > we were using previously. This has made a fairly minor difference to the UI > (padding/spacing/fonts have changed a little) but has allowed us to tidy up a > few things in the code. > > * The "Base" layer type is no longer selectable for layer submissions. I > noticed people sometimes selected this erroneously; it's only applicable for > openembedded-core and meta-oe basically so that they show up at the top of the > layer list. Only admins can now select this type for a layer. > > * Numerous other bugfixes, robustness improvements and code cleanups. > > Thanks very much to everyone who has contributed to the layer index code up to > now (and to BitBake / tinfoil, which we rely upon to extract the information > from the metadata), but I'd like to give particular thanks to Michael > Halstead, Yi Zhao, Konrad Scherer, Robert Yang and Aníbal Limón for making > this upgrade possible. Paul, and everyone above, many thanks for your contributions to the Layer Index which is definitely a great tool for our community! It encourages and simplifies reuse and sharing of all recipes! The update looks really good, and as Andreas says, the top #3 features will make a big difference. > > > Also integrated were the Recipe Reporting System (RRS) which powers > http://recipes.yoctoproject.org and other distro comparison support, but these > will take a bit more time to properly enable so I'll send out a separate email > with further details when they are ready. > > As always, please let me know if you have any comments or notice any issues. > (I've already seen a few minor problems in the update logs so I'll be looking > into those.) > > Cheers, > Paul > > -- > Paul Eggleton > Intel Open Source Technology Centre-- > ___ > yocto mailing list > yo...@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][sumo][PATCH 2/2] grpc: move it from oe to networking layer
From: Armin Kuster
grpc has dependancy on meta-networking packages.
Signed-off-by: Armin Kuster
(cherry picked from commit 251878e8b6b993b159c949f7e4860faf085e17f5)
Signed-off-by: Nicolas Dechesne
---
...001-CMakeLists.txt-Fix-grpc_cpp_plugin-path-during-cross.patch | 0
...0001-CMakeLists.txt-Fix-libraries-installation-for-Linux.patch | 0
.../0004-CMakeLists.txt-Find-c-ares-in-target-sysroot-alone.patch | 0
{meta-oe => meta-networking}/recipes-devtools/grpc/grpc_1.8.5.bb | 0
4 files changed, 0 insertions(+), 0 deletions(-)
rename {meta-oe =>
meta-networking}/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-grpc_cpp_plugin-path-during-cross.patch
(100%)
rename {meta-oe =>
meta-networking}/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-libraries-installation-for-Linux.patch
(100%)
rename {meta-oe =>
meta-networking}/recipes-devtools/grpc/grpc/0004-CMakeLists.txt-Find-c-ares-in-target-sysroot-alone.patch
(100%)
rename {meta-oe => meta-networking}/recipes-devtools/grpc/grpc_1.8.5.bb (100%)
diff --git
a/meta-oe/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-grpc_cpp_plugin-path-during-cross.patch
b/meta-networking/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-grpc_cpp_plugin-path-during-cross.patch
similarity index 100%
rename from
meta-oe/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-grpc_cpp_plugin-path-during-cross.patch
rename to
meta-networking/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-grpc_cpp_plugin-path-during-cross.patch
diff --git
a/meta-oe/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-libraries-installation-for-Linux.patch
b/meta-networking/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-libraries-installation-for-Linux.patch
similarity index 100%
rename from
meta-oe/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-libraries-installation-for-Linux.patch
rename to
meta-networking/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-libraries-installation-for-Linux.patch
diff --git
a/meta-oe/recipes-devtools/grpc/grpc/0004-CMakeLists.txt-Find-c-ares-in-target-sysroot-alone.patch
b/meta-networking/recipes-devtools/grpc/grpc/0004-CMakeLists.txt-Find-c-ares-in-target-sysroot-alone.patch
similarity index 100%
rename from
meta-oe/recipes-devtools/grpc/grpc/0004-CMakeLists.txt-Find-c-ares-in-target-sysroot-alone.patch
rename to
meta-networking/recipes-devtools/grpc/grpc/0004-CMakeLists.txt-Find-c-ares-in-target-sysroot-alone.patch
diff --git a/meta-oe/recipes-devtools/grpc/grpc_1.8.5.bb
b/meta-networking/recipes-devtools/grpc/grpc_1.8.5.bb
similarity index 100%
rename from meta-oe/recipes-devtools/grpc/grpc_1.8.5.bb
rename to meta-networking/recipes-devtools/grpc/grpc_1.8.5.bb
--
2.18.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][sumo][PATCH 0/2] Fixed required for Yocto 2.0 compliance check
These changes are needed in order to pass the YP 2.0 compliance check script
(yocto-check-layer). One change is a backport from master, the other one is
fixed in master in a different way, and the backport looks inappropriate for a
stable branch.
Armin Kuster (1):
grpc: move it from oe to networking layer
Nicolas Dechesne (1):
meta-multimedia: fixup LAYERDEPENDS
meta-multimedia/conf/layer.conf | 2 +-
...1-CMakeLists.txt-Fix-grpc_cpp_plugin-path-during-cross.patch | 0
...01-CMakeLists.txt-Fix-libraries-installation-for-Linux.patch | 0
...004-CMakeLists.txt-Find-c-ares-in-target-sysroot-alone.patch | 0
.../recipes-devtools/grpc/grpc_1.8.5.bb | 0
5 files changed, 1 insertion(+), 1 deletion(-)
rename {meta-oe =>
meta-networking}/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-grpc_cpp_plugin-path-during-cross.patch
(100%)
rename {meta-oe =>
meta-networking}/recipes-devtools/grpc/grpc/0001-CMakeLists.txt-Fix-libraries-installation-for-Linux.patch
(100%)
rename {meta-oe =>
meta-networking}/recipes-devtools/grpc/grpc/0004-CMakeLists.txt-Find-c-ares-in-target-sysroot-alone.patch
(100%)
rename {meta-oe => meta-networking}/recipes-devtools/grpc/grpc_1.8.5.bb (100%)
--
2.18.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][sumo][PATCH 1/2] meta-multimedia: fixup LAYERDEPENDS
libebml depends on dos2unix classe since 26dafa0f3542 (libebml: inherit dos2unix), so LAYERDEPENDS needs to be updated accordingly, otherwise we are getting a ParseError: ERROR: ParseError at /srv/work/oe/meta-openembedded/meta-multimedia/recipes-mkv/libebml/libebml_1.3.0.bb:13: Could not inherit file classes/dos2unix.bbclass It was initially found with yocto-check-layer script. In OE/master branch, the dos2unix class was moved to oe-core, so the problem does not exist in master, and this patch is less invasive than cherry pick the change from master (move dos2unix from meta-oe to oe-core). Signed-off-by: Nicolas Dechesne --- meta-multimedia/conf/layer.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-multimedia/conf/layer.conf b/meta-multimedia/conf/layer.conf index cfedf2f6b..a1dfed4e9 100644 --- a/meta-multimedia/conf/layer.conf +++ b/meta-multimedia/conf/layer.conf @@ -27,6 +27,6 @@ BBFILE_PRIORITY_multimedia-layer = "6" # cause compatibility issues with other layers LAYERVERSION_multimedia-layer = "1" -LAYERDEPENDS_multimedia-layer = "core" +LAYERDEPENDS_multimedia-layer = "core openembedded-layer" LAYERSERIES_COMPAT_multimedia-layer = "sumo" -- 2.18.0 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][sumo][PATCH] protobuf: make python-protobuf dependency optional and default to off
On Wed, Sep 26, 2018 at 7:36 AM Paul Eggleton
wrote:
>
> A dependency on python-protobuf was added in commit
> 5f6fcfd36272768a3ff9078c07c572cf5dc01ccd for the sole purpose of
> providing a ptest, however python-protobuf is in meta-python and thus
> this means that meta-oe would depend on meta-python by default (assuming
> your distro enables ptest by default), and we don't want that - meta-oe
> isn't supposed to depend upon any layer other than openembedded-core.
> Luckily we can still have a ptest even without the python support, so
> add a PACKAGECONFIG and leave it disabled by default.
>
> Note: the PACKAGECONFIG here is not particularly useful since it's only
> about what goes into the -ptest package and thus also the dependency. I
> contemplated just using LANG_SUPPORT instead, but PACKAGECONFIG does
> have the advantage that it's introspectable and fairly well understood
> so in the end I went with it.
>
> Signed-off-by: Paul Eggleton
thanks Paul! With this patch applied and after cherry-picking
251878e8b6b9 (grpc: move it from oe to networking layer) from master,
then yocto-check-layer reports that meta-oe is passing the compliance.
I will send the backport for grpc shortly.
> ---
> meta-oe/recipes-devtools/protobuf/protobuf_3.5.1.bb | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/meta-oe/recipes-devtools/protobuf/protobuf_3.5.1.bb
> b/meta-oe/recipes-devtools/protobuf/protobuf_3.5.1.bb
> index 1ffb79da7..073dfaef0 100644
> --- a/meta-oe/recipes-devtools/protobuf/protobuf_3.5.1.bb
> +++ b/meta-oe/recipes-devtools/protobuf/protobuf_3.5.1.bb
> @@ -12,7 +12,7 @@ DEPENDS = "zlib"
> DEPENDS_append_class-target = " protobuf-native"
> RDEPENDS_${PN}-compiler = "${PN}"
> RDEPENDS_${PN}-dev += "${PN}-compiler"
> -RDEPENDS_${PN}-ptest = "bash python-protobuf"
> +RDEPENDS_${PN}-ptest = "bash ${@bb.utils.contains('PACKAGECONFIG', 'python',
> 'python-protobuf', '', d)}"
>
> LIC_FILES_CHKSUM = "file://LICENSE;md5=35953c752efc9299b184f91bef540095"
>
> @@ -24,13 +24,16 @@ SRC_URI =
> "git://github.com/google/protobuf.git;branch=3.5.x \
>file://run-ptest \
>"
>
> +PACKAGECONFIG ??= ""
> +PACKAGECONFIG[python] = ",,"
> +
> EXTRA_OECONF += " --with-protoc=echo"
>
> inherit autotools-brokensep pkgconfig ptest
>
> S = "${WORKDIR}/git"
> TEST_SRC_DIR="examples"
> -LANG_SUPPORT="cpp python"
> +LANG_SUPPORT = "cpp ${@bb.utils.contains('PACKAGECONFIG', 'python',
> 'python', '', d)}"
>
> do_compile_ptest() {
> # Modify makefile to use the cross-compiler
> --
> 2.17.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
Re: [oe] meta-oe and yocto-check-layer
On Tue, Sep 25, 2018 at 7:10 PM Martin Jansa wrote: > > On Tue, Sep 25, 2018 at 03:05:19PM +0200, Nicolas Dechesne wrote: > > On Tue, Sep 25, 2018 at 12:29 PM Martin Jansa > > wrote: > > > > > > On Tue, Sep 25, 2018 at 12:24:31PM +0200, Martin Jansa wrote: > > > > > meta-oe: add meta-python in LAYERDEPENDS (needed for protobuf) > > > > > > > > This causes another circular dependency which we don't want, doesn't it? > > > > What are the issues with circular dependency? LAYERDEPENDS only lists > > each layers own dependencies, which is helpful for integrators to know > > which layer they need to pull into bblayers.conf. If all layers from > > LAYERDEPENDS are pulled in, then it is expected that each recipe will > > build fine. > > It prevents using these layers separately. > > Now people can include just meta-oe without meta-python (as long as they > fix or mask the python-protobuf dependency from protobuf-ptest - which > is a bug not a feature). > > If they have circular dependency then everybody using meta-oe will be > forced to use meta-python as well and then why should we keep them in > separate layers? It would be the same as adding all meta-python recipes > into meta-oe. It is not because there are circular dependencies that meta-oe requires meta-python, it is because of protobuf , it really depends on meta-python... I am tempted to agree with Paul, we should make the dependency explicitly optional using PACKAGECONFIG instead of requiring users to fix/mask it. > > There was similar issue with meta-perl not so long time ago, before with > meta-multimedia and meta-networking.. so if we don't fix these issues > properly and just add more dependencies from meta-oe, then whole > meta-openembedded as a repository will became one layer soon. agreed. I think it's good to spot these issues and fix them as they come. > > > The only circular dependency that I am aware is with yocto-check-layer > > script , and I sent a patch yesterday to fix this issue. With this > > patch, yocto-check-layer works fine even when layers have inter > > dependencies. > > > > https://patchwork.openembedded.org/patch/155113/ > > > > > > > > Especially if it's caused only by python-protobuf runtime dependency > > > added in: > > > > > > https://patchwork.openembedded.org/patch/146867/ > > > > yes. this is the culprit. > > > > > > > > > On Tue, Sep 25, 2018 at 11:44 AM Nicolas Dechesne < > > > > nicolas.deche...@linaro.org> wrote: > > > > > > > > > hi Armin, > > > > > > > > > > On Tue, Sep 25, 2018 at 8:59 AM Nicolas Dechesne > > > > > wrote: > > > > > > > > > > > > On Mon, Sep 24, 2018 at 11:51 PM akuster808 > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 09/24/2018 02:03 PM, Paul Eggleton wrote: > > > > > > > > Hi Nicolas, > > > > > > > > > > > > > > > > On Monday, 24 September 2018 10:05:02 PM NZST Nicolas Dechesne > > > > > > > > wrote: > > > > > > > >> hi Armin, Paul, Richard, > > > > > > > >> > > > > > > > >> I was looking at getting the compliance report for meta-oe > > > > > > > >> (sumo > > > > > > > >> branch), and I have found a few issues. > > > > > > > >> > > > > > > > >> * in meta-openembedded/sumo, grpc is in meta-oe layer, while it > > > > > > > >> depends on meta-networking (c-ares). It was fixes in master, > > > > > > > >> with > > > > > > > >> 251878e8b6b9 (grpc: move it from oe to networking layer), so I > > > > > > > >> think > > > > > > > >> this fix needs to be backported to sumo as well if we want the > > > > > > > >> YP > > > > > 2.0 > > > > > > > >> compliance script to even work. If agreed, once merged, please > > > > > > > >> let > > > > > me > > > > > > > >> know so that I can try again to generate a compliance report. > > > > > > > > Is it appropriate to make such moves in a stable branch? I > > > > > > > > wouldn't
Re: [oe] meta-oe and yocto-check-layer
On Tue, Sep 25, 2018 at 12:29 PM Martin Jansa wrote: > > On Tue, Sep 25, 2018 at 12:24:31PM +0200, Martin Jansa wrote: > > > meta-oe: add meta-python in LAYERDEPENDS (needed for protobuf) > > > > This causes another circular dependency which we don't want, doesn't it? What are the issues with circular dependency? LAYERDEPENDS only lists each layers own dependencies, which is helpful for integrators to know which layer they need to pull into bblayers.conf. If all layers from LAYERDEPENDS are pulled in, then it is expected that each recipe will build fine. The only circular dependency that I am aware is with yocto-check-layer script , and I sent a patch yesterday to fix this issue. With this patch, yocto-check-layer works fine even when layers have inter dependencies. https://patchwork.openembedded.org/patch/155113/ > > Especially if it's caused only by python-protobuf runtime dependency added in: > > https://patchwork.openembedded.org/patch/146867/ yes. this is the culprit. > > > On Tue, Sep 25, 2018 at 11:44 AM Nicolas Dechesne < > > nicolas.deche...@linaro.org> wrote: > > > > > hi Armin, > > > > > > On Tue, Sep 25, 2018 at 8:59 AM Nicolas Dechesne > > > wrote: > > > > > > > > On Mon, Sep 24, 2018 at 11:51 PM akuster808 > > > wrote: > > > > > > > > > > > > > > > > > > > > On 09/24/2018 02:03 PM, Paul Eggleton wrote: > > > > > > Hi Nicolas, > > > > > > > > > > > > On Monday, 24 September 2018 10:05:02 PM NZST Nicolas Dechesne > > > > > > wrote: > > > > > >> hi Armin, Paul, Richard, > > > > > >> > > > > > >> I was looking at getting the compliance report for meta-oe (sumo > > > > > >> branch), and I have found a few issues. > > > > > >> > > > > > >> * in meta-openembedded/sumo, grpc is in meta-oe layer, while it > > > > > >> depends on meta-networking (c-ares). It was fixes in master, with > > > > > >> 251878e8b6b9 (grpc: move it from oe to networking layer), so I > > > > > >> think > > > > > >> this fix needs to be backported to sumo as well if we want the YP > > > 2.0 > > > > > >> compliance script to even work. If agreed, once merged, please let > > > me > > > > > >> know so that I can try again to generate a compliance report. > > > > > > Is it appropriate to make such moves in a stable branch? I wouldn't > > > have > > > > > > thought so. > > > > > > > > > > > > > > > > We have to. Per my understanding and why I tried very hard to make > > > > > meta-openembedded clean ( appears I failed) is that if you want to be > > > > > Yocto Compliant and include any layer that does not pass this test, > > > > > you > > > > > can not become Yocto Compliant. > > > > > > > > I believe that we want meta-openembedded to be compliant, and a good > > > > example in general. I will send a backport your way for this change. > > > > > > Running the compliance script on meta-oe turned out to be an > > > interesting exercise ;) > > > > > > I have found several issues, which I have mentioned in a few different > > > threads, so I will summary here. > > > > > > * oe-core: fix the yocto-check-layer for dependency loop > > > * I have the following local commits in meta-oe: > > > meta-oe: add meta-python in LAYERDEPENDS (needed for protobuf) > > > grpc: move it from oe to networking layer > > > meta-multimedia: fixup LAYERDEPENDS (for dos2unix issue) > > > > > > With all changes above, the compliance script finds another issue with > > > meta-xfce: > > > > > > AssertionError: Adding layer meta-xfce changed signatures. > > > 7 signatures changed, initial differences (first hash before, second > > > after): > > >vim:do_install: 588d445122dccf317f15b0dd852f3888 -> > > > ec086472d75d663c2fe836b935517810 > > > > > > This is definitely a violation of one our rule since adding meta-xfce > > > changed changes vim recipe. > > > > > > > > > > > > > > > > > Or relax your rules!!!. > > > > > > > > > > - armin > > > > > >> * in order to run the compliance report, i locally added
Re: [oe] meta-oe and yocto-check-layer
hi Armin,
On Tue, Sep 25, 2018 at 8:59 AM Nicolas Dechesne
wrote:
>
> On Mon, Sep 24, 2018 at 11:51 PM akuster808 wrote:
> >
> >
> >
> > On 09/24/2018 02:03 PM, Paul Eggleton wrote:
> > > Hi Nicolas,
> > >
> > > On Monday, 24 September 2018 10:05:02 PM NZST Nicolas Dechesne wrote:
> > >> hi Armin, Paul, Richard,
> > >>
> > >> I was looking at getting the compliance report for meta-oe (sumo
> > >> branch), and I have found a few issues.
> > >>
> > >> * in meta-openembedded/sumo, grpc is in meta-oe layer, while it
> > >> depends on meta-networking (c-ares). It was fixes in master, with
> > >> 251878e8b6b9 (grpc: move it from oe to networking layer), so I think
> > >> this fix needs to be backported to sumo as well if we want the YP 2.0
> > >> compliance script to even work. If agreed, once merged, please let me
> > >> know so that I can try again to generate a compliance report.
> > > Is it appropriate to make such moves in a stable branch? I wouldn't have
> > > thought so.
> > >
> >
> > We have to. Per my understanding and why I tried very hard to make
> > meta-openembedded clean ( appears I failed) is that if you want to be
> > Yocto Compliant and include any layer that does not pass this test, you
> > can not become Yocto Compliant.
>
> I believe that we want meta-openembedded to be compliant, and a good
> example in general. I will send a backport your way for this change.
Running the compliance script on meta-oe turned out to be an
interesting exercise ;)
I have found several issues, which I have mentioned in a few different
threads, so I will summary here.
* oe-core: fix the yocto-check-layer for dependency loop
* I have the following local commits in meta-oe:
meta-oe: add meta-python in LAYERDEPENDS (needed for protobuf)
grpc: move it from oe to networking layer
meta-multimedia: fixup LAYERDEPENDS (for dos2unix issue)
With all changes above, the compliance script finds another issue with
meta-xfce:
AssertionError: Adding layer meta-xfce changed signatures.
7 signatures changed, initial differences (first hash before, second after):
vim:do_install: 588d445122dccf317f15b0dd852f3888 ->
ec086472d75d663c2fe836b935517810
This is definitely a violation of one our rule since adding meta-xfce
changed changes vim recipe.
>
> >
> > Or relax your rules!!!.
> >
> > - armin
> > >> * in order to run the compliance report, i locally added
> > >> networking-layer in meta-oe/conf/layer.conf, and it creates a
> > >> dependency loop since meta-oe <-> meta-networking. I found out that
> > >> yocto-check-layer doesn't like that too much, and brutally fails. The
> > >> following patch makes yocto-check-layer work again even with
> > >> dependency loop. I am going to do a few more tests and send that over
> > >> as a patch.
> > >>
> > >> diff --git a/scripts/lib/checklayer/__init__.py
> > >> b/scripts/lib/checklayer/__init__.py
> > >> index 2618416fab..0cc9bf3b6d 100644
> > >> --- a/scripts/lib/checklayer/__init__.py
> > >> +++ b/scripts/lib/checklayer/__init__.py
> > >> @@ -151,11 +151,21 @@ def add_layer_dependencies(bblayersconf, layer,
> > >> layers, logger):
> > >> logger.debug('Processing dependencies %s for layer %s.' % \
> > >> (depends, layer['name']))
> > >>
> > >> +# To avoid never ending recursion, we keep track of layers while
> > >> +# they are being processed in this 'static' attribute.
> > >> +if not hasattr(recurse_dependencies, "layers"):
> > >> +recurse_dependencies.layers = []
> > >> +
> > >> for depend in depends.split():
> > >> # core (oe-core) is suppose to be provided
> > >> if depend == 'core':
> > >> continue
> > >>
> > >> +if depend in recurse_dependencies.layers:
> > >> +continue
> > >> +
> > >> +recurse_dependencies.layers.append(depend)
> > >> +
> > >> layer_depend = _find_layer_depends(depend, layers)
> > >> if not layer_depend:
> > >> logger.error('Layer %s depends on %s and isn\'t found.'
> > >> % \
> > > Patch looks reasonable to me FWIW.
> > >
> > > Cheers,
> > > Paul
> > >
> > >
> >
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] meta-oe and yocto-check-layer
On Mon, Sep 24, 2018 at 11:51 PM akuster808 wrote:
>
>
>
> On 09/24/2018 02:03 PM, Paul Eggleton wrote:
> > Hi Nicolas,
> >
> > On Monday, 24 September 2018 10:05:02 PM NZST Nicolas Dechesne wrote:
> >> hi Armin, Paul, Richard,
> >>
> >> I was looking at getting the compliance report for meta-oe (sumo
> >> branch), and I have found a few issues.
> >>
> >> * in meta-openembedded/sumo, grpc is in meta-oe layer, while it
> >> depends on meta-networking (c-ares). It was fixes in master, with
> >> 251878e8b6b9 (grpc: move it from oe to networking layer), so I think
> >> this fix needs to be backported to sumo as well if we want the YP 2.0
> >> compliance script to even work. If agreed, once merged, please let me
> >> know so that I can try again to generate a compliance report.
> > Is it appropriate to make such moves in a stable branch? I wouldn't have
> > thought so.
> >
>
> We have to. Per my understanding and why I tried very hard to make
> meta-openembedded clean ( appears I failed) is that if you want to be
> Yocto Compliant and include any layer that does not pass this test, you
> can not become Yocto Compliant.
I believe that we want meta-openembedded to be compliant, and a good
example in general. I will send a backport your way for this change.
>
> Or relax your rules!!!.
>
> - armin
> >> * in order to run the compliance report, i locally added
> >> networking-layer in meta-oe/conf/layer.conf, and it creates a
> >> dependency loop since meta-oe <-> meta-networking. I found out that
> >> yocto-check-layer doesn't like that too much, and brutally fails. The
> >> following patch makes yocto-check-layer work again even with
> >> dependency loop. I am going to do a few more tests and send that over
> >> as a patch.
> >>
> >> diff --git a/scripts/lib/checklayer/__init__.py
> >> b/scripts/lib/checklayer/__init__.py
> >> index 2618416fab..0cc9bf3b6d 100644
> >> --- a/scripts/lib/checklayer/__init__.py
> >> +++ b/scripts/lib/checklayer/__init__.py
> >> @@ -151,11 +151,21 @@ def add_layer_dependencies(bblayersconf, layer,
> >> layers, logger):
> >> logger.debug('Processing dependencies %s for layer %s.' % \
> >> (depends, layer['name']))
> >>
> >> +# To avoid never ending recursion, we keep track of layers while
> >> +# they are being processed in this 'static' attribute.
> >> +if not hasattr(recurse_dependencies, "layers"):
> >> +recurse_dependencies.layers = []
> >> +
> >> for depend in depends.split():
> >> # core (oe-core) is suppose to be provided
> >> if depend == 'core':
> >> continue
> >>
> >> +if depend in recurse_dependencies.layers:
> >> +continue
> >> +
> >> +recurse_dependencies.layers.append(depend)
> >> +
> >> layer_depend = _find_layer_depends(depend, layers)
> >> if not layer_depend:
> >> logger.error('Layer %s depends on %s and isn\'t found.' %
> >> \
> > Patch looks reasonable to me FWIW.
> >
> > Cheers,
> > Paul
> >
> >
>
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] meta-multimedia: fixup LAYERDEPENDS
On Mon, Sep 24, 2018 at 10:27 PM Khem Raj wrote: > > Dos2unix is in oe-core now please try with master ouch. sorry, i missed that. I noticed the issue while running the YP 2.0 compliance script against sumo branch... how do we get that fixed in sumo then? can we apply something like the below patch on sumo directly? > > On Mon, Sep 24, 2018 at 1:19 PM Nicolas Dechesne > wrote: >> >> libebml depends on dos2unix classe since 26dafa0f3542 (libebml: inherit >> dos2unix), so LAYERDEPENDS needs to be updated accordingly, otherwise we are >> getting a ParseError: >> >> ERROR: ParseError at >> /srv/work/oe/meta-openembedded/meta-multimedia/recipes-mkv/libebml/libebml_1.3.0.bb:13: >> Could not inherit file classes/dos2unix.bbclass >> >> It was initially found with yocto-check-layer script. >> >> Signed-off-by: Nicolas Dechesne >> --- >> meta-multimedia/conf/layer.conf | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta-multimedia/conf/layer.conf >> b/meta-multimedia/conf/layer.conf >> index cfedf2f6b..a1dfed4e9 100644 >> --- a/meta-multimedia/conf/layer.conf >> +++ b/meta-multimedia/conf/layer.conf >> @@ -27,6 +27,6 @@ BBFILE_PRIORITY_multimedia-layer = "6" >> # cause compatibility issues with other layers >> LAYERVERSION_multimedia-layer = "1" >> >> -LAYERDEPENDS_multimedia-layer = "core" >> +LAYERDEPENDS_multimedia-layer = "core openembedded-layer" >> >> LAYERSERIES_COMPAT_multimedia-layer = "sumo" >> -- >> 2.18.0 >> >> -- >> ___ >> 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] meta-multimedia: fixup LAYERDEPENDS
libebml depends on dos2unix classe since 26dafa0f3542 (libebml: inherit dos2unix), so LAYERDEPENDS needs to be updated accordingly, otherwise we are getting a ParseError: ERROR: ParseError at /srv/work/oe/meta-openembedded/meta-multimedia/recipes-mkv/libebml/libebml_1.3.0.bb:13: Could not inherit file classes/dos2unix.bbclass It was initially found with yocto-check-layer script. Signed-off-by: Nicolas Dechesne --- meta-multimedia/conf/layer.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-multimedia/conf/layer.conf b/meta-multimedia/conf/layer.conf index cfedf2f6b..a1dfed4e9 100644 --- a/meta-multimedia/conf/layer.conf +++ b/meta-multimedia/conf/layer.conf @@ -27,6 +27,6 @@ BBFILE_PRIORITY_multimedia-layer = "6" # cause compatibility issues with other layers LAYERVERSION_multimedia-layer = "1" -LAYERDEPENDS_multimedia-layer = "core" +LAYERDEPENDS_multimedia-layer = "core openembedded-layer" LAYERSERIES_COMPAT_multimedia-layer = "sumo" -- 2.18.0 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] meta-oe and yocto-check-layer
hi Armin, Paul, Richard,
I was looking at getting the compliance report for meta-oe (sumo
branch), and I have found a few issues.
* in meta-openembedded/sumo, grpc is in meta-oe layer, while it
depends on meta-networking (c-ares). It was fixes in master, with
251878e8b6b9 (grpc: move it from oe to networking layer), so I think
this fix needs to be backported to sumo as well if we want the YP 2.0
compliance script to even work. If agreed, once merged, please let me
know so that I can try again to generate a compliance report.
* in order to run the compliance report, i locally added
networking-layer in meta-oe/conf/layer.conf, and it creates a
dependency loop since meta-oe <-> meta-networking. I found out that
yocto-check-layer doesn't like that too much, and brutally fails. The
following patch makes yocto-check-layer work again even with
dependency loop. I am going to do a few more tests and send that over
as a patch.
diff --git a/scripts/lib/checklayer/__init__.py
b/scripts/lib/checklayer/__init__.py
index 2618416fab..0cc9bf3b6d 100644
--- a/scripts/lib/checklayer/__init__.py
+++ b/scripts/lib/checklayer/__init__.py
@@ -151,11 +151,21 @@ def add_layer_dependencies(bblayersconf, layer,
layers, logger):
logger.debug('Processing dependencies %s for layer %s.' % \
(depends, layer['name']))
+# To avoid never ending recursion, we keep track of layers while
+# they are being processed in this 'static' attribute.
+if not hasattr(recurse_dependencies, "layers"):
+recurse_dependencies.layers = []
+
for depend in depends.split():
# core (oe-core) is suppose to be provided
if depend == 'core':
continue
+if depend in recurse_dependencies.layers:
+continue
+
+recurse_dependencies.layers.append(depend)
+
layer_depend = _find_layer_depends(depend, layers)
if not layer_depend:
logger.error('Layer %s depends on %s and isn\'t found.' % \
cheers
nico
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] Demos for the Yocto Project booth at ELCE in Edinburgh
Dear all, As usual, the Yocto Project will have a booth at the ELCE conference in Edinburgh next month. While the booth is a great opportunity for everyone to get a new sticker of your favorite project ;-) we are also very excited when developers from our community get a chance to show off the fun and cool things they build thanks to the Yocto Project! If you want to bring any of your cool demo on the YP booth, please send me an email so that we can plan and discuss any of the logistics! Also, don't forget the YP Dev Day Europe, which is right after ELCE, in Edinburgh, more information can be found here: https://www.yoctoproject.org/yocto-project-dev-day-europe-2018/ cheers nico -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] gpsd: upgrade to 3.17
This is based on out of tree recipe in meta-medusa-dist, from Tristan
Ramseyer. Tested on Dragonboard 410c.
Signed-off-by: Nicolas Dechesne
---
...prefix-includepy-with-sysroot-and-drop-sy.patch | 52 --
.../0001-include-sys-ttydefaults.h.patch | 4 +-
...disable-html-and-man-docs-building-becaus.patch | 11 +++--
.../gpsd/{gpsd_3.16.bb => gpsd_3.17.bb}| 4 +-
4 files changed, 38 insertions(+), 33 deletions(-)
rename meta-oe/recipes-navigation/gpsd/{gpsd-3.16 =>
gpsd-3.17}/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch (54%)
rename meta-oe/recipes-navigation/gpsd/{gpsd-3.16 =>
gpsd-3.17}/0001-include-sys-ttydefaults.h.patch (94%)
rename meta-oe/recipes-navigation/gpsd/{gpsd-3.16 =>
gpsd-3.17}/0004-SConstruct-disable-html-and-man-docs-building-becaus.patch (89%)
rename meta-oe/recipes-navigation/gpsd/{gpsd_3.16.bb => gpsd_3.17.bb} (97%)
diff --git
a/meta-oe/recipes-navigation/gpsd/gpsd-3.16/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
b/meta-oe/recipes-navigation/gpsd/gpsd-3.17/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
similarity index 54%
rename from
meta-oe/recipes-navigation/gpsd/gpsd-3.16/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
rename to
meta-oe/recipes-navigation/gpsd/gpsd-3.17/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
index 2ea3226a4..1fa27c210 100644
---
a/meta-oe/recipes-navigation/gpsd/gpsd-3.16/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
+++
b/meta-oe/recipes-navigation/gpsd/gpsd-3.17/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
@@ -39,36 +39,42 @@ Signed-off-by: Peter A. Bigot
1 file changed, 9 insertions(+)
diff --git a/SConstruct b/SConstruct
-index 6c93311..cde8b3d 100644
+index 3318bb48..e1c4f963 100644
--- a/SConstruct
+++ b/SConstruct
-@@ -1148,6 +1148,12 @@ else:
- basecflags += ' -coverage'
- ldflags += ' -coverage'
- ldshared += ' -coverage'
-+
-+if env['sysroot']:
-+print "Prefixing includepy '%s' with sysroot prefix" % includepy
-+includepy = os.path.normpath("%s/%s/%s/%s" % (env['sysroot'],
env['prefix'], env['includedir'], includepy))
-+print "'%s'" % includepy
-+
- # in case CC/CXX was set to the scan-build wrapper,
- # ensure that we build the python modules with scan-build, too
- if env['CC'] is None or env['CC'].find('scan-build') < 0:
-@@ -1408,11 +1414,14 @@ if not env['python']:
+@@ -934,7 +934,7 @@ else:
+
+ # Set up configuration for target Python
+
+-PYTHON_LIBDIR_CALL = 'sysconfig.get_python_lib()'
++PYTHON_LIBDIR_CALL = 'sysconfig.get_python_lib(plat_specific=1)'
+
+ PYTHON_CONFIG_NAMES = ['CC', 'CXX', 'OPT', 'BASECFLAGS',
+'CCSHARED', 'LDSHARED', 'SO', 'INCLUDEPY', 'LDFLAGS']
+@@ -1364,7 +1364,7 @@ else:
+LINK=ldshared,
+SHLIBPREFIX="",
+SHLIBSUFFIX=python_config['SO'],
+- CPPPATH=[python_config['INCLUDEPY']],
++ CPPPATH=[os.path.normpath("%s/%s/%s/%s" %
(env['sysroot'], env['prefix'], env['includedir'],
python_config['INCLUDEPY']))] if env['sysroot'] else
[python_config['INCLUDEPY']],
+CPPFLAGS=python_config['OPT'],
+CFLAGS=python_config['BASECFLAGS'],
+CXXFLAGS=python_config['BASECFLAGS'])
+@@ -1662,12 +1662,15 @@ if ((not env['debug'] and not env['profiling'] and not
env['nostrip']
+ if not env['python']:
python_install = []
else:
- python_lib_dir = env['python_libdir']
-+python_lib_dir = python_lib_dir.replace(env['sysroot'], '')
- python_module_dir = python_lib_dir + os.sep + 'gps'
- python_extensions_install = python_env.Install( DESTDIR +
python_module_dir,
- python_built_extensions)
- if not env['debug'] and not env['profiling'] and not env['nostrip'] and
not sys.platform.startswith('darwin'):
++python_libdir = python_libdir.replace(env['sysroot'], '')
+ python_module_dir = python_libdir + os.sep + 'gps'
+ python_extensions_install = python_env.Install(DESTDIR +
python_module_dir,
+python_built_extensions)
+ if ((not env['debug'] and not env['profiling&
[oe] [PATCH] glmark2: Upgrade to 2017.07 release
Upstream added new dependency on udev in
a7ae55d NativeStateDRM: Probe the DRM node path to use with udev
Patch removed since it was merged upstream in
5fcdba1 wayland: Fix destruction order of surface-related objects
Signed-off-by: Nicolas Dechesne
---
...ace-should-be-destoryed-after-the-wl_wind.patch | 34 --
meta-oe/recipes-benchmark/glmark2/glmark2_git.bb | 7 ++---
2 files changed, 3 insertions(+), 38 deletions(-)
delete mode 100644
meta-oe/recipes-benchmark/glmark2/files/0001-Fix-wl_surface-should-be-destoryed-after-the-wl_wind.patch
diff --git
a/meta-oe/recipes-benchmark/glmark2/files/0001-Fix-wl_surface-should-be-destoryed-after-the-wl_wind.patch
b/meta-oe/recipes-benchmark/glmark2/files/0001-Fix-wl_surface-should-be-destoryed-after-the-wl_wind.patch
deleted file mode 100644
index 439508102..0
---
a/meta-oe/recipes-benchmark/glmark2/files/0001-Fix-wl_surface-should-be-destoryed-after-the-wl_wind.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From 9c74ec83e2929b1d5ab65d5137b6ba42edeb332d Mon Sep 17 00:00:00 2001
-From: Yong Gan
-Date: Tue, 27 Oct 2015 18:15:20 +0800
-Subject: [PATCH] Fix: wl_surface should be destoryed after the wl_window
- destroyed.
-
-Upstream-Status: Submitted [https://github.com/glmark2/glmark2/issues/12]
-
-Signed-off-by: Yong Gan
-
- src/native-state-wayland.cpp | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/src/native-state-wayland.cpp b/src/native-state-wayland.cpp
-index 41fc743..cdcdf34 100644
a/src/native-state-wayland.cpp
-+++ b/src/native-state-wayland.cpp
-@@ -56,10 +56,10 @@ NativeStateWayland::~NativeStateWayland()
- wl_shell_surface_destroy(window_->shell_surface);
- if (window_->opaque_reqion)
- wl_region_destroy(window_->opaque_reqion);
--if (window_->surface)
--wl_surface_destroy(window_->surface);
- if (window_->native)
- wl_egl_window_destroy(window_->native);
-+if (window_->surface)
-+wl_surface_destroy(window_->surface);
- delete window_;
- }
-
---
-1.9.1
-
diff --git a/meta-oe/recipes-benchmark/glmark2/glmark2_git.bb
b/meta-oe/recipes-benchmark/glmark2/glmark2_git.bb
index 85d7bf16e..4c5e0567b 100644
--- a/meta-oe/recipes-benchmark/glmark2/glmark2_git.bb
+++ b/meta-oe/recipes-benchmark/glmark2/glmark2_git.bb
@@ -8,18 +8,17 @@ LICENSE = "GPLv3+ & SGIv1"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
file://COPYING.SGI;beginline=5;md5=269cdab4af6748677acce51d9aa13552"
-DEPENDS = "libpng jpeg"
+DEPENDS = "libpng jpeg udev"
-PV = "2014.03+${SRCPV}"
+PV = "2017.07+${SRCPV}"
COMPATIBLE_HOST_rpi = "${@bb.utils.contains('MACHINE_FEATURES',
'vc4graphics', '.*-linux*', 'null', d)}"
SRC_URI = "git://github.com/glmark2/glmark2.git;protocol=https \
file://build-Check-packages-to-be-used-by-the-enabled-flavo.patch \
-file://0001-Fix-wl_surface-should-be-destoryed-after-the-wl_wind.patch \
file://Fix-configure-for-sqrt-check.patch \
"
-SRCREV = "9b1070fe9c5cf908f323909d3c8cbed08022abe8"
+SRCREV = "182dcbffe5c8483eadff025b429ee1aacc69c6c2"
S = "${WORKDIR}/git"
--
2.11.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] OpenEmbedded 2017 General Meeting
On Mon, May 1, 2017 at 12:40 PM, Richard Purdie wrote: > > On Mon, 2017-05-01 at 12:27 +0200, Andrea Galbusera wrote: > > > > > > On Mon, May 1, 2017 at 12:02 PM, Andrei Gherzan > > wrote: > > > On Wed, Apr 19, 2017 at 9:48 PM, Sean Hudson > > m> wrote: > > > > The board would like to hold a general meeting with all members. > > > Under > > > > the new by-laws of the OpenEmbedded organization, we can meet > > > > electronically. This will also fulfill the requirement for an > > > annual, > > > > general meeting. > > > > > > > > Planned Date/Time: > > > > Wednesday, May 3rd, at 8am US-CDT(UTC-06:00)/3pm CET(UTC+01:00) > > > > > > > > Wiki page with full details, including teleconference information > > > here: > > > > http://www.openembedded.org/wiki/2017_General_Meeting > > > > > > It seems like there is not Edit button for me to add my username to > > > the attendee list. > > Same for me... > > FWIW once I'd logged in I could add my name to the list... well, it's the same for me. In the 'view source' page, i can see this: == You do not have permission to edit this page, for the following reason: The action you have requested is limited to users in the group: Administrators. > > > Cheers, > > Richard > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] vdpau in morty
hi, someone reported to me to that vlc failed to build in our builds/release, ERROR: Nothing PROVIDES 'libvdpau' I am trying to understand what has happened, it looks like several recipes have recently added depends on vdpau, vlc: Add packageconfig for vdpau mpv: Add libvdpau to DEPENDS however the recipe does not exist in morty (only in master). Am I missing anything here? or did we just miss the recipe? cheers. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][morty][PATCH] gpsd: fix multilib build
While testing arm 64/32 multi, the following issue was observed:
WARNING: gpsd-3.14-r0 do_package: QA Issue: gpsd: Files/directories were
installed but not shipped in any package:
/usr/lib/libgpsd.so.22.0
/usr/lib/libgps.so.22
/usr/lib/libgpsd.so.22.0.0
/usr/lib/libgpsd.so.22
/usr/lib/libgps.so.22.0.0
/usr/lib/libgps.so
/usr/lib/libgps.so.22.0
/usr/lib/libgpsd.so
/usr/lib/pkgconfig
/usr/lib/pkgconfig/libgpsd.pc
/usr/lib/pkgconfig/libgps.pc
Please set FILES such that these items are packaged. Alternatively if they are
unneeded, avoid installing them or delete them within do_install.
gpsd: 11 installed and not shipped files. [installed-vs-shipped]
WARNING: gpsd-3.14-r0 do_package_qa: QA Issue: /usr/bin/cgps contained in
package gps-utils requires libgps.so.22()(64bit), but no providers found in
RDEPENDS_gps-utils? [file-rdeps]
WARNING: gpsd-3.14-r0 do_package_qa: QA Issue: /usr/sbin/gpsdctl contained in
package gpsd requires libgps.so.22()(64bit), but no providers found in
RDEPENDS_gpsd? [file-rdeps]
WARNING: gpsd-3.14-r0 do_package_qa: QA Issue: /usr/bin/gpsctl contained in
package gpsd-gpsctl requires libgps.so.22()(64bit), but no providers found in
RDEPENDS_gpsd-gpsctl? [file-rdeps]
WARNING: gpsd-3.14-r0 do_package_qa: QA Issue: gpsd-dbg: found library in wrong
location: /usr/lib/.debug/libgpsd.so.22.0.0
gpsd-dbg: found library in wrong location: /usr/lib/.debug/libgps.so.22.0.0
[libdir]
gpsd SConstruct file defaults to using '/lib' suffix, which needs to be
overriden in the recipe.
Signed-off-by: Nicolas Dechesne
Signed-off-by: Martin Jansa
(cherry picked from commit 45837e6c567b1b9ff9d152a7e2a752488d313455)
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
b/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
index b7b8968..4d00fea 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
+++ b/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
@@ -46,6 +46,7 @@ EXTRA_OESCONS = " \
strip='false' \
chrpath='yes' \
systemd='${SYSTEMD_OESCONS}' \
+libdir='${libdir}' \
${PACKAGECONFIG_CONFARGS} \
"
# this cannot be used, because then chrpath is not found and only static lib
is built
--
2.10.2
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] gpsd: fix multilib build
While testing arm 64/32 multi, the following issue was observed:
WARNING: gpsd-3.14-r0 do_package: QA Issue: gpsd: Files/directories were
installed but not shipped in any package:
/usr/lib/libgpsd.so.22.0
/usr/lib/libgps.so.22
/usr/lib/libgpsd.so.22.0.0
/usr/lib/libgpsd.so.22
/usr/lib/libgps.so.22.0.0
/usr/lib/libgps.so
/usr/lib/libgps.so.22.0
/usr/lib/libgpsd.so
/usr/lib/pkgconfig
/usr/lib/pkgconfig/libgpsd.pc
/usr/lib/pkgconfig/libgps.pc
Please set FILES such that these items are packaged. Alternatively if they are
unneeded, avoid installing them or delete them within do_install.
gpsd: 11 installed and not shipped files. [installed-vs-shipped]
WARNING: gpsd-3.14-r0 do_package_qa: QA Issue: /usr/bin/cgps contained in
package gps-utils requires libgps.so.22()(64bit), but no providers found in
RDEPENDS_gps-utils? [file-rdeps]
WARNING: gpsd-3.14-r0 do_package_qa: QA Issue: /usr/sbin/gpsdctl contained in
package gpsd requires libgps.so.22()(64bit), but no providers found in
RDEPENDS_gpsd? [file-rdeps]
WARNING: gpsd-3.14-r0 do_package_qa: QA Issue: /usr/bin/gpsctl contained in
package gpsd-gpsctl requires libgps.so.22()(64bit), but no providers found in
RDEPENDS_gpsd-gpsctl? [file-rdeps]
WARNING: gpsd-3.14-r0 do_package_qa: QA Issue: gpsd-dbg: found library in wrong
location: /usr/lib/.debug/libgpsd.so.22.0.0
gpsd-dbg: found library in wrong location: /usr/lib/.debug/libgps.so.22.0.0
[libdir]
gpsd SConstruct file defaults to using '/lib' suffix, which needs to be
overriden in the recipe.
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
b/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
index b7b8968..4d00fea 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
+++ b/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
@@ -46,6 +46,7 @@ EXTRA_OESCONS = " \
strip='false' \
chrpath='yes' \
systemd='${SYSTEMD_OESCONS}' \
+libdir='${libdir}' \
${PACKAGECONFIG_CONFARGS} \
"
# this cannot be used, because then chrpath is not found and only static lib
is built
--
2.7.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] android-tools: fix do_install
On Fri, Nov 18, 2016 at 11:26 AM, Koen Kooi wrote:
> -if [ grep -q "ext4_utils" "${TOOLS}" ] ; then
> +export TOOLSFILE="${WORKDIR}/tools.txt"
> +echo ${TOOLS} > ${TOOLSFILE}
> +
> +if grep -q "ext4_utils" ${TOOLSFILE} ; then
how about this instead?
echo "${TOOLS}" | grep -q "ext4_utils"
it looks simpler and more readable to me.
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] android-tools: fix native build
On Fri, Oct 21, 2016 at 9:10 AM, Koen Kooi wrote:
> +if [ grep -q "ext4_utils" "${TOOLS}" ] ; then
> +install -D -p -m0755 ${S}/system/core/libsparse/simg_dump.py
> ${D}${bindir}/simg_dump
> +install -D -p -m0755 ${S}/system/extras/ext4_utils/mkuserimg.sh
> ${D}${bindir}/mkuserimg
> +
> +install -m0755 ${B}/ext4_utils/ext2simg ${D}${bindir}
> +install -m0755 ${B}/ext4_utils/ext4fixup ${D}${bindir}
> +install -m0755 ${B}/ext4_utils/img2simg ${D}${bindir}
> +install -m0755 ${B}/ext4_utils/make_ext4fs ${D}${bindir}
> +install -m0755 ${B}/ext4_utils/simg2img ${D}${bindir}
> +install -m0755 ${B}/ext4_utils/simg2simg ${D}${bindir}
> +fi
> +
> +if [ grep -q "adb " "${TOOLS}" ] ; then
> +install -m0755 ${B}/adb/adb ${D}${bindir}i
> +fi
> +
> +if [ grep -q "adbd" "${TOOLS}" ] ; then
> +install -m0755 ${B}/adbd/adbd ${D}${bindir}
> +install -D -p -m0644 ${WORKDIR}/android-tools-adbd.service \
> + ${D}${systemd_unitdir}/system/android-tools-adbd.service
> +fi
> +
> +if [ grep -q "fastboot" "${TOOLS}" ] ; then
> +install -m0755 ${B}/fastboot/fastboot ${D}${bindir}
> +fi
> +
> +if [ grep -q "mkbootimg" "${TOOLS}" ] ; then
> + install -m0755 ${B}/mkbootimg/mkbootimg ${D}${bindir}
> +fi
sorry to notice that just now.. but how can this work? the 'grep'
statements above are wrong and non functional. I was trying to build
the recipe and noticed that no files get installed. The current
implementation will lead to:
$ grep "ext4_utils" "adb fastboot ext4_utils mkbootimg adbd"
grep: adb fastboot ext4_utils mkbootimg adbd: No such file or directory
Both the target and -native build fails, with target build i end up
with this error
ERROR: android-tools-5.1.1.r37-r0 do_package:
SYSTEMD_SERVICE_android-tools value android-tools-adbd.service does
not exist
ERROR: android-tools-5.1.1.r37-r0 do_package: Function failed:
systemd_populate_packages
I suppose it was tested without systemd , so there was no obvious
error, but the resulting packages were empty..
I also needed to add libcap in DEPENDS, to get the compile task to work.
nico
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH 1/2] gpsd: make sure the recipe uses LDFLAGS
since commit fa436aeb3242cbfdbbe16d448d45bce8eb5b74fd in OE core, we are seeing
GNU_HASH QA failure when building gpsd. Since this commit we default to setting
the wrong linker hash style to detect such errors in recipes.
gpsd is using scons which does not take LDFLAGS into account, and LDFLAGS need
to be passed from the environment, using LINKFLAGS variable.
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
b/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
index 822fc24..537facc 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
+++ b/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
@@ -55,12 +55,14 @@ do_compile_prepend() {
export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}"
export PKG_CONFIG="PKG_CONFIG_SYSROOT_DIR=\"${PKG_CONFIG_SYSROOT_DIR}\"
pkg-config"
export STAGING_PREFIX="${STAGING_DIR_HOST}/${prefix}"
+export LINKFLAGS="${LDFLAGS}"
}
do_install() {
export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}"
export PKG_CONFIG="PKG_CONFIG_SYSROOT_DIR=\"${PKG_CONFIG_SYSROOT_DIR}\"
pkg-config"
export STAGING_PREFIX="${STAGING_DIR_HOST}/${prefix}"
+export LINKFLAGS="${LDFLAGS}"
export DESTDIR="${D}"
# prefix is used for RPATH and DESTDIR/prefix for instalation
--
2.7.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH 2/2] Revert "gpsd, foxtrotgps: blacklist, fails to build with new binutils-2.27"
This reverts commit 8c29023f1fe5881f3e001704eb9e5d398777d4a6.
---
meta-oe/recipes-navigation/foxtrotgps/foxtrotgps_1.1.1.bb | 3 +--
meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb | 3 ---
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/meta-oe/recipes-navigation/foxtrotgps/foxtrotgps_1.1.1.bb
b/meta-oe/recipes-navigation/foxtrotgps/foxtrotgps_1.1.1.bb
index 32b20c3..d91cbcb 100644
--- a/meta-oe/recipes-navigation/foxtrotgps/foxtrotgps_1.1.1.bb
+++ b/meta-oe/recipes-navigation/foxtrotgps/foxtrotgps_1.1.1.bb
@@ -6,8 +6,7 @@ LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"
DEPENDS = "curl gtk+ libglade sqlite3 libexif gpsd bluez4 intltool-native"
-PNBLACKLIST[foxtrotgps] ?= "Depends on broken gpsd"
-#PNBLACKLIST[foxtrotgps] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5',
'bluez5 conflicts with bluez4 and bluez5 is selected in DISTRO_FEATURES', '',
d)}"
+PNBLACKLIST[foxtrotgps] ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5',
'bluez5 conflicts with bluez4 and bluez5 is selected in DISTRO_FEATURES', '',
d)}"
SRC_URI = "http://www.foxtrotgps.org/releases/${BP}.tar.gz";
SRC_URI[md5sum] = "6777d448ee9d3ba195f9d26ea90e3163"
diff --git a/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
b/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
index 537facc..6158e97 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
+++ b/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb
@@ -139,6 +139,3 @@ RPROVIDES_${PN} += "${PN}-systemd"
RREPLACES_${PN} += "${PN}-systemd"
RCONFLICTS_${PN} += "${PN}-systemd"
SYSTEMD_SERVICE_${PN} = "${PN}.socket"
-
-# http://errors.yoctoproject.org/Errors/Details/81000/
-PNBLACKLIST[gpsd] ?= "BROKEN: fails to build with new binutils 2.27"
--
2.7.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH 0/2] Fix gpsd builds
gpsd is broken in master since we default to using the wrong linker hash style in gcc-cross. The purpose of that change was to find broken recipes, so here we are! Once gpsd is fixed to properly prograge LDFLAGS we can revert the patch that blacklisted that recipe. The first patch is probably a good candidate for stable branch, if that series get merged, i will submit a separate patch for that. Nicolas Dechesne (2): gpsd: make sure the recipe uses LDFLAGS Revert "gpsd, foxtrotgps: blacklist, fails to build with new binutils-2.27" meta-oe/recipes-navigation/foxtrotgps/foxtrotgps_1.1.1.bb | 3 +-- meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb | 5 ++--- 2 files changed, 3 insertions(+), 5 deletions(-) -- 2.7.0 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH v2] sysbench: add new recipe
The project used to be hosted on Sourceforge, then Launchpad, and it moved to
Github. The last stable release (0.4.12) cannot be found on Sourceforge anymore,
and is not available (as tarball) on github. So using the tarball from Launchpad
instead. We can move to github when the next release happens (which will be the
first one from github).
Tested with and without mysql, with and without aio.
Signed-off-by: Nicolas Dechesne
---
Changes in v2:
* fixed "QA Issue: sysbench rdepends on libaio, but it isn't a build dependency"
* added aio PACKAGECONFIG, and keep it disable by default
.../recipes-benchmark/sysbench/sysbench_0.4.12.bb | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
diff --git a/meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
b/meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
new file mode 100644
index 000..3c69548
--- /dev/null
+++ b/meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
@@ -0,0 +1,26 @@
+SUMMARY = "System performance benchmark"
+HOMEPAGE = "http://github.com/akopytov/sysbench";
+SECTION = "console/tests"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+
+inherit autotools
+
+# The project has moved from Sourceforge to Launchpad, to Github. Use the
source tarball from
+# Launchpad until the next release is available from Github.
+SRC_URI =
"https://launchpad.net/ubuntu/+archive/primary/+files/${BPN}_${PV}.orig.tar.gz";
+
+SRC_URI[md5sum] = "3a6d54fdd3fe002328e4458206392b9d"
+SRC_URI[sha256sum] =
"83fa7464193e012c91254e595a89894d8e35b4a38324b52a5974777e3823ea9e"
+
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'largefile',
'largefile', '', d)}"
+PACKAGECONFIG[largefile] = "--enable-largefile,--disable-largefile,,"
+PACKAGECONFIG[aio] = "--enable-aio,--disable-aio,libaio,"
+PACKAGECONFIG[mysql] = "--with-mysql \
+--with-mysql-includes=${STAGING_INCDIR}/mysql \
+--with-mysql-libs=${STAGING_LIBDIR}, \
+--without-mysql,mysql5"
+
+do_configure_prepend() {
+touch ${S}/NEWS ${S}/AUTHORS
+}
--
2.7.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] sysbench: add new recipe
The project used to be hosted on Sourceforge, then Launchpad, and it moved to
Github. The last stable release (0.4.12) cannot be found on Sourceforge anymore,
and is not available (as tarball) on github. So using the tarball from Launchpad
instead. We can move to github when the next release happens (which will be the
first one from github).
Tested with and without mysql.
Signed-off-by: Nicolas Dechesne
---
.../recipes-benchmark/sysbench/sysbench_0.4.12.bb | 25 ++
1 file changed, 25 insertions(+)
create mode 100644 meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
diff --git a/meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
b/meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
new file mode 100644
index 000..5873470
--- /dev/null
+++ b/meta-oe/recipes-benchmark/sysbench/sysbench_0.4.12.bb
@@ -0,0 +1,25 @@
+SUMMARY = "System performance benchmark"
+HOMEPAGE = "http://github.com/akopytov/sysbench";
+SECTION = "console/tests"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+
+inherit autotools
+
+# The project has moved from Sourceforge to Launchpad, to Github. Use the
source tarball from
+# Launchpad until the next release is available from Github.
+SRC_URI =
"https://launchpad.net/ubuntu/+archive/primary/+files/${BPN}_${PV}.orig.tar.gz";
+
+SRC_URI[md5sum] = "3a6d54fdd3fe002328e4458206392b9d"
+SRC_URI[sha256sum] =
"83fa7464193e012c91254e595a89894d8e35b4a38324b52a5974777e3823ea9e"
+
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'largefile',
'largefile', '', d)}"
+PACKAGECONFIG[largefile] = "--enable-largefile,--disable-largefile,,"
+PACKAGECONFIG[mysql] = "--with-mysql \
+--with-mysql-includes=${STAGING_INCDIR}/mysql \
+--with-mysql-libs=${STAGING_LIBDIR}, \
+--without-mysql,mysql5"
+
+do_configure_prepend() {
+touch ${S}/NEWS ${S}/AUTHORS
+}
--
2.7.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] android-tools: Fix, enhance and move from meta-shr
On Sat, Jul 2, 2016 at 7:15 PM, Khem Raj wrote: >> Obviously, it doesn't prevent to get current recipe moved to meta-oe. >> It's just a heads up :) > > Thanks for.update. I think this really should go into oe core. Since sparse > file system is across many devices +1. for sure.. that would be very nice. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-filesystems][master][PATCH] sshfs-fuse: update to 2.8
hi Zoltan,
On Fri, Jul 1, 2016 at 10:03 AM, Zoltan Kuscsik
wrote:
> Signed-off-by: Zoltan Kuscsik
> ---
> .../files/0001-Makefile-fix-path-for-sshfs.1.patch | 27
> ++
> .../{sshfs-fuse_2.5.bb => sshfs-fuse_2.8.bb} | 9
> 2 files changed, 31 insertions(+), 5 deletions(-)
> create mode 100644
> meta-filesystems/recipes-filesystems/sshfs-fuse/files/0001-Makefile-fix-path-for-sshfs.1.patch
> rename meta-filesystems/recipes-filesystems/sshfs-fuse/{sshfs-fuse_2.5.bb =>
> sshfs-fuse_2.8.bb} (65%)
>
> diff --git
> a/meta-filesystems/recipes-filesystems/sshfs-fuse/files/0001-Makefile-fix-path-for-sshfs.1.patch
>
> b/meta-filesystems/recipes-filesystems/sshfs-fuse/files/0001-Makefile-fix-path-for-sshfs.1.patch
> new file mode 100644
> index 000..39c1f04
> --- /dev/null
> +++
> b/meta-filesystems/recipes-filesystems/sshfs-fuse/files/0001-Makefile-fix-path-for-sshfs.1.patch
> @@ -0,0 +1,27 @@
> +From e3cd445a4ee44a16faa646d7b642d02eea62b1f8 Mon Sep 17 00:00:00 2001
> +From: Zoltan Kuscsik
> +Date: Fri, 1 Jul 2016 09:30:31 +0200
> +Subject: [PATCH] Makefile: fix path for sshfs.1
> +
> +Fix source path when build directory differs
> +from the source dir.
please check
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations.
And at least add upstream-status tag and link to your github pull
request ( i saw that you sent it already!)
> +---
> + Makefile.am | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/Makefile.am b/Makefile.am
> +index f003bae..3d8f9cb 100644
> +--- a/Makefile.am
> b/Makefile.am
> +@@ -24,7 +24,7 @@ sshfs.1: sshfs.1.in
> + $(AM_V_GEN)sed \
> + -e 's,__IDMAP_DEFAULT__,$(IDMAP_DEFAULT),g' \
> + -e 's,__UNMOUNT_COMMAND__,$(UNMOUNT_COMMAND),g' \
> +- sshfs.1.tmp || exit 1; \
> ++ <$(srcdir)/sshfs.1.in >sshfs.1.tmp || exit 1; \
> + mv sshfs.1.tmp sshfs.1
> +
> + if SSH_NODELAY_SO
> +--
> +1.9.1
> +
> diff --git
> a/meta-filesystems/recipes-filesystems/sshfs-fuse/sshfs-fuse_2.5.bb
> b/meta-filesystems/recipes-filesystems/sshfs-fuse/sshfs-fuse_2.8.bb
> similarity index 65%
> rename from meta-filesystems/recipes-filesystems/sshfs-fuse/sshfs-fuse_2.5.bb
> rename to meta-filesystems/recipes-filesystems/sshfs-fuse/sshfs-fuse_2.8.bb
> index c54cfcb..64ccdac 100644
> --- a/meta-filesystems/recipes-filesystems/sshfs-fuse/sshfs-fuse_2.5.bb
> +++ b/meta-filesystems/recipes-filesystems/sshfs-fuse/sshfs-fuse_2.8.bb
> @@ -6,12 +6,11 @@ LICENSE = "GPLv2"
> DEPENDS = "glib-2.0 fuse"
> LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>
> -SRC_URI = "${SOURCEFORGE_MIRROR}/fuse/${BP}.tar.gz"
> -S = "${WORKDIR}/${BP}"
> +SRC_URI =
> "git://github.com/libfuse/sshfs;tag=b2fa7593586b141298e6159f40f521d2b0f4f894 \
this change is legit indeed, but probably need an explanation in the
commit msg as to why you are switching from tarball to git.
> + file://0001-Makefile-fix-path-for-sshfs.1.patch"
> +
> +S = "${WORKDIR}/git"
>
> inherit autotools pkgconfig
>
> FILES_${PN} += "${libdir}/sshnodelay.so"
> -
> -SRC_URI[md5sum] = "17494910db8383a366b1301e5f5148a9"
> -SRC_URI[sha256sum] =
> "e9171452e5d0150b9c6a2158fd2e2dcefb5d5d03ba4d208949e00a3a46c6e63e"
> --
> 1.9.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
Re: [oe] [PATCH 00/36] Jethro-next pull request
hi Armin, On Thu, Apr 28, 2016 at 11:00 PM, Armin Kuster wrote: > Please consider these changes for jethro-next > > The following changes since commit c305ac5d2f5285d5eec8952a4ca7f3b4f89aed96: > > python-m2crypto: fix SSLv2 symbol issue (2016-03-09 20:10:13 +0100) > > are available in the git repository at: > > git://github.com/akuster/meta-openembedded akuster/jethro-next > https://github.com/akuster/meta-openembedded/tree/akuster/jethro-next I had sent an email to backport this one on jethro as well: 9ece354 openbox: add run time dependency on openbox-theme-clearlooks I am not sure if you saw the original email, so, i am resending the request. thanks! nico -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] openbox: add run time dependency on openbox-theme-clearlooks
Martin, Armin,
this patch was merged in master, and it applies cleanly on jethro, is
that possible to get it merged in jethro as well?
thanks
On Mon, Apr 4, 2016 at 3:35 PM, Nicolas Dechesne
wrote:
> Without this default theme install , openbox is unable to start, and shows the
> following message:
>
> dragonboard-410c:/home/linaro# openbox
> ObRender-Message: Unable to load the theme 'Clearlooks'
> ObRender-Message: Falling back to the default theme 'Clearlooks'
> ObRender-Message: Unable to load the theme 'Clearlooks'
> Openbox-Message: Unable to load a theme.
>
> As discussed in [1] , the solution is to make sure that
> openbox-theme-clearlooks
> is always included.
>
> [1]
> https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg47153.html
>
> Signed-off-by: Nicolas Dechesne
> ---
> meta-oe/recipes-graphics/openbox/openbox_3.6.1.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-oe/recipes-graphics/openbox/openbox_3.6.1.bb
> b/meta-oe/recipes-graphics/openbox/openbox_3.6.1.bb
> index 9f42177..b354ae7 100644
> --- a/meta-oe/recipes-graphics/openbox/openbox_3.6.1.bb
> +++ b/meta-oe/recipes-graphics/openbox/openbox_3.6.1.bb
> @@ -37,7 +37,7 @@ python populate_packages_prepend() {
> do_split_packages(d, theme_dir, '(.*)', theme_name, '${PN} theme for
> %s', extra_depends='', allow_dirs=True)
> }
>
> -RDEPENDS_${PN} += "${PN}-core ${PN}-config"
> +RDEPENDS_${PN} += "${PN}-core ${PN}-config ${PN}-theme-clearlooks"
> FILES_${PN}-core = "${bindir}/openbox ${libdir}/*${SOLIBS}"
>
> FILES_${PN}-lxde += "${datadir}/lxde/ \
> --
> 2.8.0.rc3
>
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] anyone using docker for OE builds?
On Thu, Apr 21, 2016 at 9:09 PM, Cliff Brake wrote: > Thanks for all the information. > > After a week or so experimenting with Docker, I've come up with a > solution I like: > > https://hub.docker.com/r/cbrake/oe-build/ > > Also wrote about it here: > > http://bec-systems.com/site/1281/using-docker-for-oeyocto-builds thanks for the write up.. that got me into finally looking at it ;-) is there a (nice) solution in case my host UID/GID isn't 1000/1000? I definitely need to mount volumes for the persistent data , but i need to be able to read/write these volumes from containers and host, so ideally i would like my containers to inherit UID/GID from an existing user on the host. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] openbox: add run time dependency on openbox-theme-clearlooks
Without this default theme install , openbox is unable to start, and shows the
following message:
dragonboard-410c:/home/linaro# openbox
ObRender-Message: Unable to load the theme 'Clearlooks'
ObRender-Message: Falling back to the default theme 'Clearlooks'
ObRender-Message: Unable to load the theme 'Clearlooks'
Openbox-Message: Unable to load a theme.
As discussed in [1] , the solution is to make sure that openbox-theme-clearlooks
is always included.
[1]
https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg47153.html
Signed-off-by: Nicolas Dechesne
---
meta-oe/recipes-graphics/openbox/openbox_3.6.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-graphics/openbox/openbox_3.6.1.bb
b/meta-oe/recipes-graphics/openbox/openbox_3.6.1.bb
index 9f42177..b354ae7 100644
--- a/meta-oe/recipes-graphics/openbox/openbox_3.6.1.bb
+++ b/meta-oe/recipes-graphics/openbox/openbox_3.6.1.bb
@@ -37,7 +37,7 @@ python populate_packages_prepend() {
do_split_packages(d, theme_dir, '(.*)', theme_name, '${PN} theme for %s',
extra_depends='', allow_dirs=True)
}
-RDEPENDS_${PN} += "${PN}-core ${PN}-config"
+RDEPENDS_${PN} += "${PN}-core ${PN}-config ${PN}-theme-clearlooks"
FILES_${PN}-core = "${bindir}/openbox ${libdir}/*${SOLIBS}"
FILES_${PN}-lxde += "${datadir}/lxde/ \
--
2.8.0.rc3
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] openbox themes
On Wed, Mar 30, 2016 at 8:19 PM, Khem Raj wrote: > > Do you have XDG_DATA_DIRS variable set to include /usr/share, try something > like > > export XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/share > > before launching openbox, if that works then may be you should add it to > /etc/profile > via a post processing hook or some such. that doesn't change anything. without any openbox-theme installed , it fails to start. I can briefly see the mouse pointer on the screen, before it dies. nico -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] openbox themes
hi, i am not sure if this is something new or not.. and I believe it used to work for me in the past (but I am not 100% sure..). If I only add openbox in my image, it would fail to start with something like this: dragonboard-410c:/home/linaro# openbox & ObRender-Message: Unable to load the theme 'Clearlooks' ObRender-Message: Falling back to the default theme 'Clearlooks' ObRender-Message: Unable to load the theme 'Clearlooks' Openbox-Message: Unable to load a theme. After I add openbox-theme-clearlooks in my image, openbox would start normally. As I said, I am fairly sure I had tried that before, and I don't remember adding a theme myself but it might have come as a dependency of some sort.. Anyways, can someone confirm if openbox is expected to fail when no theme is installed? If so, should we gracefully handle this in openbox recipe and add a default theme as RDEPENDS? thank! nico -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] checking if a patch was approved
On Tue, Oct 27, 2015 at 12:12 AM, Ivan Sergio Borgonovo wrote: > I saw many patch passing by and I submitted a couple about > meta-toolchain-qt5. > I didn't see any message from Otavio or Martin "approving" a patches. > > How can I check if it was approved other than pulling from the repo/checking > github? > > Or if there is no place to check... consider this a ping ;) all commits are published on openembedded-comm...@lists.openembedded.org mailing list, and in general you see when it's pushed in master-next, then in master.. i have a mail filter that checks my name there.. it's the poor man solution.. but it works. Note that the email trigger has been broken for 2 weeks.. but i suspect this is a temporary issue that should be fixed.. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Updates to mesa and llvm
Le 26 oct. 2015 22:46, "Philip Balister" a écrit : > > Recently I need to get the llvmpipe driver running with mesa. I ended up > adding a llvm-3.7 recipe and updating mesa to 10.6.8. Not sure if going > to 11.x.y also works. I was told 2 weeks ago that updates to 10.6.8 was too late for this cycle, and Ross said we could cherry pick patches from upstream if needed.. As for 11.x, we have patches ready for next cycle.. As soon as we can update master we will send them. > > I'd like to upstream these since they configuration actually worked and > performance was much better. I recall some discussion lately about this > process and wanted to make sure I didn't break anything :) > > I'll send on the llvm 3.7 stuff this week, since it should work in > parallel with the older recipe. I do need to move the license file > checksum into the version specific piece. > > The timing on the mesa update is trickier since we are trying to > stabilize the oe-core release. > > Comments? Will adding another llvm recipe cause trouble for other packages? > > Philip > -- > ___ > 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
Re: [oe] [meta-browser] Recipes draft for Chromium V45 and V47
hi, On Fri, Oct 9, 2015 at 1:31 PM, Zoltan Kuscsik wrote: > So far it is tested on Wayland builds (ARM 32bit and ARM 64bit): > > https://github.com/linaro-home/meta-browser just for the record.. I am using/testing this set of recipes on IFC6410 (armv7) and DragonBoard 410c (armv8), and so far so good. it would be good if the helper script google-chrome could parse a 'default' config file, so that as a downstream user it is easy for me to hook my own customizations in this script, something like . /etc/default/google-chrome nico -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] "sub" machine types?
On Fri, Sep 4, 2015 at 9:35 AM, Steffen Sledz wrote: > We have some products which differ in bootloaders (u-boot) and kernel device > trees only. They use the same kernel and root filesystem. > > Does OE have concepts for this? Or any suggestions to realize this without > building for many machines? most BSP layers use SOC_FAMILY, see [1] for this type of things, such that you can create 'SOC' specific packages that are reused across multiple (OE) machines. That sounds like that would help in your situation. [1] http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-SOC_FAMILY -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 3/5] emacs: Un-blacklist, seems to work fine with new qemu
On Thu, Feb 5, 2015 at 5:10 PM, Dan McGregor wrote: > In my testing I explicitly disabled x11 in PACKAGECONFIG. I suspect > there may be something broken in its X11 support, maybe I should > remove x11 from the default PACKAGECONFIG set? indeed, without X11 emacs now works fine in non X11 environment. i am not sure what to say then... if i use debian or ubuntu on the same board, emacs works fine with or without X11, so we must be doing something wrong in the recipe.. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 3/5] emacs: Un-blacklist, seems to work fine with new qemu
On Wed, Feb 4, 2015 at 9:29 PM, Dan McGregor wrote: > > I've only tested the build with armv7 and x86, but the build > doesn't segfault anymore. The last time this was tested was > with qemu 1.5, we're now using 2.1. > > While here, don't copy stuff from the sysroot into the qemu tree > just use the sysroot itself. I tried this patch, and I was able to build and install emacs package, on an armv7 board, using master branch as of today. emacs seems to be working fine under X11 here, however when I run it from a console without X11 (over ssh, or on the serial console), emacs would start, but I am not able to use it. keyboard is no working from within the application. ctrl+z isn't working as well, so I need to manually kill the process. i know the emacs build process isn't straightforward, and maybe we aim to support only emacs + X11 with our recipe.. i am not sure.. have you tried to use emacs without X11? thanks -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-games][PATCH] supertuxkart: initial recipe for v0.8.1
* the 2 patches are needed to build against mesa 10, they are backported from
upstream, since there is no new release as of yet.
* tested on Snapdragon (ARMv7 + adreno GPU), running freedreno Mesa Gallium
driver
* Build tested for qemux86
Signed-off-by: Nicolas Dechesne
---
On some distro like Debian/Ubuntu the package is split in supertuxkart and
supertuxkart-data to separate the rather large (~300MB) platform
independent media files. I haven't done it here, but that could be
done if needed..
...01-Use-system-s-glext.h-glxext.h-on-linux.patch | 28 ++
...ch-from-jpirie-for-fixing-mesa-10-compila.patch | 33 ++
recipes-games/supertuxkart/supertuxkart_0.8.1.bb | 19 +
3 files changed, 80 insertions(+)
create mode 100644
recipes-games/supertuxkart/files/0001-Use-system-s-glext.h-glxext.h-on-linux.patch
create mode 100644
recipes-games/supertuxkart/files/0002-Applied-patch-from-jpirie-for-fixing-mesa-10-compila.patch
create mode 100644 recipes-games/supertuxkart/supertuxkart_0.8.1.bb
diff --git
a/recipes-games/supertuxkart/files/0001-Use-system-s-glext.h-glxext.h-on-linux.patch
b/recipes-games/supertuxkart/files/0001-Use-system-s-glext.h-glxext.h-on-linux.patch
new file mode 100644
index 000..cf61c44
--- /dev/null
+++
b/recipes-games/supertuxkart/files/0001-Use-system-s-glext.h-glxext.h-on-linux.patch
@@ -0,0 +1,28 @@
+From 8771edf61fcf3ced4afb9e9bc08897f575d86834 Mon Sep 17 00:00:00 2001
+From: Deve
+Date: Sat, 17 May 2014 09:18:25 +0200
+Subject: [PATCH 1/2] Use system's glext.h/glxext.h on linux.
+
+---
+ lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.h
b/lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.h
+index 7f9e0df..586d0c4 100644
+--- a/lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.h
b/lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.h
+@@ -61,9 +61,9 @@
+ #include
+ #include
+ #if defined(_IRR_OPENGL_USE_EXTPOINTER_)
+- #include "glext.h"
++ #include
+ #undef GLX_ARB_get_proc_address // avoid problems with local glxext.h
+- #include "glxext.h"
++ #include
+ #endif
+ #endif
+
+--
+2.1.4
+
diff --git
a/recipes-games/supertuxkart/files/0002-Applied-patch-from-jpirie-for-fixing-mesa-10-compila.patch
b/recipes-games/supertuxkart/files/0002-Applied-patch-from-jpirie-for-fixing-mesa-10-compila.patch
new file mode 100644
index 000..3162ba6
--- /dev/null
+++
b/recipes-games/supertuxkart/files/0002-Applied-patch-from-jpirie-for-fixing-mesa-10-compila.patch
@@ -0,0 +1,33 @@
+From 1a922afa0b03b9cc35e9fb4945deb3f73a5d39b4 Mon Sep 17 00:00:00 2001
+From: Deve
+Date: Sat, 17 May 2014 09:21:07 +0200
+Subject: [PATCH 2/2] Applied patch from jpirie for fixing mesa 10 compilation
+ problems.
+
+---
+ lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.h
b/lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.h
+index 586d0c4..b39f8b5 100644
+--- a/lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.h
b/lib/irrlicht/source/Irrlicht/COpenGLExtensionHandler.h
+@@ -49,6 +49,7 @@
+ #define NO_SDL_GLEXT
+ #include
+ #include
++ typedef void (APIENTRYP PFNGLBLENDEQUATIONPROC) (GLenum mode);
+ #include "glext.h"
+ #else
+ #if defined(_IRR_OPENGL_USE_EXTPOINTER_)
+@@ -61,6 +62,7 @@
+ #include
+ #include
+ #if defined(_IRR_OPENGL_USE_EXTPOINTER_)
++ typedef void (APIENTRYP PFNGLBLENDEQUATIONPROC) (GLenum mode);
+ #include
+ #undef GLX_ARB_get_proc_address // avoid problems with local glxext.h
+ #include
+--
+2.1.4
+
diff --git a/recipes-games/supertuxkart/supertuxkart_0.8.1.bb
b/recipes-games/supertuxkart/supertuxkart_0.8.1.bb
new file mode 100644
index 000..126bbd2
--- /dev/null
+++ b/recipes-games/supertuxkart/supertuxkart_0.8.1.bb
@@ -0,0 +1,19 @@
+DESCRIPTION = "SuperTuxKart is a kart racing game featuring Tux and his
friends"
+HOMEAPAGE = "http://supertuxkart.sourceforge.net";
+SECTION = "x11/application"
+LICENSE = "GPLv2 & GPLv3+ "
+LIC_FILES_CHKSUM = "file://COPYING;md5=a71cb78659d60f2ced58a594cb65bfba"
+
+DEPENDS = "libogg libvorbis libxrandr virtual/libgl openal-soft fribidi curl"
+
+inherit cmake
+
+S = "${WORKDIR}/SuperTuxKart-${PV}"
+
+SRC_URI =
"http://sourceforge.net/projects/supertuxkart/files/SuperTuxKart/${PV}/supertuxkart-${PV}-src.tar.bz2;protocol=https
\
+ file://0001-Use-system-s-glext.h-glxext.h-on-linux.patch \
+
file://0002-Applied-patch-from-jpirie-for-fixing-mesa-10-compila.patch"
+
+SRC_URI[md5sum] = "aa31ec
Re: [oe] initramfs only supported in x86?
On Thu, May 15, 2014 at 7:13 PM, Adam Lee wrote: > Hello everyone, I thought I'd compare the performance of booting > rootfs from MMC vs ramdisk (the way Android is doing it). Some says it > may possibly take longer in ramdisk because the rootfs has to be first > loaded into memory. I'd like to test it out myself. > > So I discovered core-image-minimal-initramfs, and thought it was > exactly what I needed. However the build doesn't go far, because its > dependency initramfs-live-install [1] only seems to support x86: > > COMPATIBLE_HOST = "(i.86|x86_64).*-linux" > > Is this the limitation of current OE? or am I just looking at the wrong > corner? i recently had to build an initrd too, and notice that as well... so i am not sure exactly what that means. I am glad you asked... however if you want to test an initrd, you can simply build *any* image and make sure to build the 'cpio' from IMAGE_FSTYPES. you can then use the generated cpio archive as an initrd. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] What is the relationship between Open Embedded for MSM and Yocto Project?
On Wed, Apr 16, 2014 at 2:02 PM, Philip Balister wrote: >> >> I found this from the git remote url of my surce code. It is >> git://codeaurora.org/quic/le/openembedded/openembedded-core >> this tree is just a fork of oe-core (upstream) which is stuck at a 2-year old commit. if this is what you are calling "OE for MSM" well then it's just a 2-year old OE. You might be calling that "for MSM" because it comes from QCOM Code Aurora git tree.. but there is no vendor change in [1] [1] https://www.codeaurora.org/cgit/quic/le/openembedded/openembedded-core/ -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Where can I get a arm cross toolchain for oe-core?
On Tue, Apr 15, 2014 at 1:42 PM, Journeyer J. Joh wrote: > I use OE for qualcomm's MDM + AP soc system. > OE is used on AP side. > > The build environment is bitbake based and I felt it like a sandbox system. > I am sorry I don't know about OE, bitbake very well.. almost I know > nothing.. > > I can build the target image. Yes. > But I wonder how I compile any 3rd party applications for my target. > I did build one by adding the application source code into the whole image > source tree. > This way builds the application as a part of the target image. I can find > it in /usr/bin with other default applications together. > > And I did build another by using a general arm cross toolchain like > arm-none-linux-gnueabi-gcc. > Using this toolchain is simple and easy. But there is no gurantee that this > toolchain has identical libc that is used in the target image. It's not > only the libc, runtime library, and hardware floating point operation > configurations are not certain, not guranteed. > > I believe there should exist one that 100% syncs with OE bitbake compile > environment. > I doubt if I can try to use just OE bitbake environment for those 3rd party > applications. > > How am I supposed to go forward? you have (at least) 2 options: 1- create 'native' OE/bitbake recipes for your own applications/libraries, that way your s/w will be integrated during the image creation. 2- use the OE SDK, which produces a toolchain and sysroot compatible with the image you've built. You can cross compile any application using this SDK and you're guaranteed that the SDK will match (libc, ...) the content of the target image. For for information about this, you can look at [1] and [2]. [1] http://www.yoctoproject.org/docs/1.5.1/ref-manual/ref-manual.html#cross-development-toolchain-generation [2] http://www.yoctoproject.org/docs/1.5.1/adt-manual/adt-manual.html -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora v2 3/3] qtwebkit-examples: add RDEPENDS for ca-certificates
From: Andre McCurdy
If qtbase is configured with openssl support then the
qtwebkit browser example apps require CA certificates.
Signed-off-by: Andre McCurdy
Signed-off-by: Nicolas Dechesne
---
recipes-qt/qt5/qt5.inc | 2 ++
recipes-qt/qt5/qtbase.inc| 4 +++-
recipes-qt/qt5/qtwebkit-examples.inc | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/recipes-qt/qt5/qt5.inc b/recipes-qt/qt5/qt5.inc
index 7669efc..d9ebbff 100644
--- a/recipes-qt/qt5/qt5.inc
+++ b/recipes-qt/qt5/qt5.inc
@@ -7,6 +7,8 @@ inherit qmake5
ICU = "icu "
ICU_powerpc = "pango"
+PACKAGECONFIG_OPENSSL ?= "openssl"
+
QT_MODULE ?= "${BPN}"
# we don't want conflicts with qt4
diff --git a/recipes-qt/qt5/qtbase.inc b/recipes-qt/qt5/qtbase.inc
index 4f81f8e..eb22e40 100644
--- a/recipes-qt/qt5/qtbase.inc
+++ b/recipes-qt/qt5/qtbase.inc
@@ -43,6 +43,8 @@ PACKAGECONFIG_FONTS ?= ""
PACKAGECONFIG_SYSTEM ?= "jpeg libpng zlib"
PACKAGECONFIG_MULTIMEDIA ?= "${@base_contains('DISTRO_FEATURES', 'pulseaudio',
'pulseaudio', '', d)}"
PACKAGECONFIG_DISTRO ?= ""
+# This is in qt5.inc, because qtwebkit-examples are using it to enable
ca-certificates dependency
+# PACKAGECONFIG_OPENSSL ?= "openssl"
PACKAGECONFIG ??= " \
release \
@@ -50,7 +52,7 @@ PACKAGECONFIG ??= " \
udev \
evdev \
widgets \
-openssl \
+${PACKAGECONFIG_OPENSSL} \
${PACKAGECONFIG_GL} \
${PACKAGECONFIG_FB} \
${PACKAGECONFIG_X11} \
diff --git a/recipes-qt/qt5/qtwebkit-examples.inc
b/recipes-qt/qt5/qtwebkit-examples.inc
index 50c28cd..84f16a4 100644
--- a/recipes-qt/qt5/qtwebkit-examples.inc
+++ b/recipes-qt/qt5/qtwebkit-examples.inc
@@ -10,3 +10,4 @@ SRC_URI += " \
DEPENDS += "qtwebkit"
RDEPENDS_${PN}-examples += "qtwebkit-qmlplugins"
+RDEPENDS_${PN}-examples += "${@base_contains('PACKAGECONFIG_OPENSSL',
'openssl', 'ca-certificates', '', d)}"
--
1.9.0
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora v2 2/3] qtbase: configure with -openssl-linked instead of -openssl
From: Andre McCurdy
Configure qtbase with -openssl-linked (instead of -openssl) to ensure
that run-time dependencies on libcryto and libssl are detected.
Signed-off-by: Andre McCurdy
Signed-off-by: Nicolas Dechesne
---
recipes-qt/qt5/qtbase.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/recipes-qt/qt5/qtbase.inc b/recipes-qt/qt5/qtbase.inc
index e4beafd..4f81f8e 100644
--- a/recipes-qt/qt5/qtbase.inc
+++ b/recipes-qt/qt5/qtbase.inc
@@ -114,7 +114,8 @@ PACKAGECONFIG[kms] = "-kms,-no-kms,kms"
# needed for qtdeclarative (qtdeclarative.do_configure fails to find quick
module without)
PACKAGECONFIG[icu] = "-icu,-no-icu,${ICU}"
PACKAGECONFIG[udev] = "-libudev,-no-libudev,udev"
-PACKAGECONFIG[openssl] = "-openssl,-no-openssl,openssl"
+# use -openssl-linked here to ensure that RDEPENDS for libcrypto and libssl
are detected
+PACKAGECONFIG[openssl] = "-openssl-linked,-no-openssl,openssl"
PACKAGECONFIG[alsa] = "-alsa,-no-alsa,alsa-lib"
PACKAGECONFIG[pulseaudio] = "-pulseaudio,-no-pulseaudio,pulseaudio"
PACKAGECONFIG[nis] = "-nis,-no-nis"
--
1.9.0
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora v2 0/3] A couple of backport for dora
Hi Martin, the following commits were recently merged in master branch. I have rebased/backported on dora and tested on ARM board. Only 1 minor had to be resolved. Can you please merge them in dora branch? Changes in v2: - cleanup commit message in 0003, as per Martin request. thanks nico Andre McCurdy (3): qtbase.inc: don't force ARM_INSTRUCTION_SET to arm qtbase: configure with -openssl-linked instead of -openssl qtwebkit-examples: add RDEPENDS for ca-certificates recipes-qt/qt5/qt5.inc | 2 ++ recipes-qt/qt5/qtbase.inc| 10 +- recipes-qt/qt5/qtwebkit-examples.inc | 1 + 3 files changed, 8 insertions(+), 5 deletions(-) -- 1.9.0 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora v2 1/3] qtbase.inc: don't force ARM_INSTRUCTION_SET to arm
From: Andre McCurdy
Forcing ARM_INSTRUCTION_SET to arm when building qtbase no longer
seems to be required.
Confirmed by forcing ARM_INSTRUCTION_SET to thumb and building
qtbase 5.1.1 and 5.2.1 tuned for both armv4t and cortexa9thf-neon.
Signed-off-by: Andre McCurdy
Signed-off-by: Nicolas Dechesne
---
recipes-qt/qt5/qtbase.inc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/recipes-qt/qt5/qtbase.inc b/recipes-qt/qt5/qtbase.inc
index 71da726..e4beafd 100644
--- a/recipes-qt/qt5/qtbase.inc
+++ b/recipes-qt/qt5/qtbase.inc
@@ -130,9 +130,6 @@ QT_CONFIG_FLAGS += " \
${EXTRA_OECONF} \
"
-# Qt uses atomic instructions not supported in thumb mode
-ARM_INSTRUCTION_SET = "arm"
-
do_generate_qt_config_file_append() {
cat >> ${QT_CONF_PATH} <http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH dora 3/3] qtwebkit-examples: add RDEPENDS for ca-certificates
On Thu, Feb 27, 2014 at 7:25 PM, Martin Jansa wrote: >> Conflicts: >> recipes-qt/qt5/qtbase.inc > > Please drop this oops. sorry. i messed up with my git aliases... and resent the same.. will fix ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora v2 2/3] qtbase: configure with -openssl-linked instead of -openssl
From: Andre McCurdy
Configure qtbase with -openssl-linked (instead of -openssl) to ensure
that run-time dependencies on libcryto and libssl are detected.
Signed-off-by: Andre McCurdy
Signed-off-by: Nicolas Dechesne
---
recipes-qt/qt5/qtbase.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/recipes-qt/qt5/qtbase.inc b/recipes-qt/qt5/qtbase.inc
index e4beafd..4f81f8e 100644
--- a/recipes-qt/qt5/qtbase.inc
+++ b/recipes-qt/qt5/qtbase.inc
@@ -114,7 +114,8 @@ PACKAGECONFIG[kms] = "-kms,-no-kms,kms"
# needed for qtdeclarative (qtdeclarative.do_configure fails to find quick
module without)
PACKAGECONFIG[icu] = "-icu,-no-icu,${ICU}"
PACKAGECONFIG[udev] = "-libudev,-no-libudev,udev"
-PACKAGECONFIG[openssl] = "-openssl,-no-openssl,openssl"
+# use -openssl-linked here to ensure that RDEPENDS for libcrypto and libssl
are detected
+PACKAGECONFIG[openssl] = "-openssl-linked,-no-openssl,openssl"
PACKAGECONFIG[alsa] = "-alsa,-no-alsa,alsa-lib"
PACKAGECONFIG[pulseaudio] = "-pulseaudio,-no-pulseaudio,pulseaudio"
PACKAGECONFIG[nis] = "-nis,-no-nis"
--
1.9.0
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora v2 3/3] qtwebkit-examples: add RDEPENDS for ca-certificates
From: Andre McCurdy
If qtbase is configured with openssl support then the
qtwebkit browser example apps require CA certificates.
Signed-off-by: Andre McCurdy
Signed-off-by: Nicolas Dechesne
Conflicts:
recipes-qt/qt5/qtbase.inc
Signed-off-by: Nicolas Dechesne
---
recipes-qt/qt5/qt5.inc | 2 ++
recipes-qt/qt5/qtbase.inc| 4 +++-
recipes-qt/qt5/qtwebkit-examples.inc | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/recipes-qt/qt5/qt5.inc b/recipes-qt/qt5/qt5.inc
index 7669efc..d9ebbff 100644
--- a/recipes-qt/qt5/qt5.inc
+++ b/recipes-qt/qt5/qt5.inc
@@ -7,6 +7,8 @@ inherit qmake5
ICU = "icu "
ICU_powerpc = "pango"
+PACKAGECONFIG_OPENSSL ?= "openssl"
+
QT_MODULE ?= "${BPN}"
# we don't want conflicts with qt4
diff --git a/recipes-qt/qt5/qtbase.inc b/recipes-qt/qt5/qtbase.inc
index 4f81f8e..eb22e40 100644
--- a/recipes-qt/qt5/qtbase.inc
+++ b/recipes-qt/qt5/qtbase.inc
@@ -43,6 +43,8 @@ PACKAGECONFIG_FONTS ?= ""
PACKAGECONFIG_SYSTEM ?= "jpeg libpng zlib"
PACKAGECONFIG_MULTIMEDIA ?= "${@base_contains('DISTRO_FEATURES', 'pulseaudio',
'pulseaudio', '', d)}"
PACKAGECONFIG_DISTRO ?= ""
+# This is in qt5.inc, because qtwebkit-examples are using it to enable
ca-certificates dependency
+# PACKAGECONFIG_OPENSSL ?= "openssl"
PACKAGECONFIG ??= " \
release \
@@ -50,7 +52,7 @@ PACKAGECONFIG ??= " \
udev \
evdev \
widgets \
-openssl \
+${PACKAGECONFIG_OPENSSL} \
${PACKAGECONFIG_GL} \
${PACKAGECONFIG_FB} \
${PACKAGECONFIG_X11} \
diff --git a/recipes-qt/qt5/qtwebkit-examples.inc
b/recipes-qt/qt5/qtwebkit-examples.inc
index 50c28cd..84f16a4 100644
--- a/recipes-qt/qt5/qtwebkit-examples.inc
+++ b/recipes-qt/qt5/qtwebkit-examples.inc
@@ -10,3 +10,4 @@ SRC_URI += " \
DEPENDS += "qtwebkit"
RDEPENDS_${PN}-examples += "qtwebkit-qmlplugins"
+RDEPENDS_${PN}-examples += "${@base_contains('PACKAGECONFIG_OPENSSL',
'openssl', 'ca-certificates', '', d)}"
--
1.9.0
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora v2 0/3] A couple of backport for dora
Hi Martin, the following commits were recently merged in master branch. I have rebased/backported on dora and tested on ARM board. Only 1 minor had to be resolved. Can you please merge them in dora branch? Changes in v2: - cleanup commit message in 0003, as per Martin request. thanks nico Andre McCurdy (3): qtbase.inc: don't force ARM_INSTRUCTION_SET to arm qtbase: configure with -openssl-linked instead of -openssl qtwebkit-examples: add RDEPENDS for ca-certificates recipes-qt/qt5/qt5.inc | 2 ++ recipes-qt/qt5/qtbase.inc| 10 +- recipes-qt/qt5/qtwebkit-examples.inc | 1 + 3 files changed, 8 insertions(+), 5 deletions(-) -- 1.9.0 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora v2 1/3] qtbase.inc: don't force ARM_INSTRUCTION_SET to arm
From: Andre McCurdy
Forcing ARM_INSTRUCTION_SET to arm when building qtbase no longer
seems to be required.
Confirmed by forcing ARM_INSTRUCTION_SET to thumb and building
qtbase 5.1.1 and 5.2.1 tuned for both armv4t and cortexa9thf-neon.
Signed-off-by: Andre McCurdy
Signed-off-by: Nicolas Dechesne
---
recipes-qt/qt5/qtbase.inc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/recipes-qt/qt5/qtbase.inc b/recipes-qt/qt5/qtbase.inc
index 71da726..e4beafd 100644
--- a/recipes-qt/qt5/qtbase.inc
+++ b/recipes-qt/qt5/qtbase.inc
@@ -130,9 +130,6 @@ QT_CONFIG_FLAGS += " \
${EXTRA_OECONF} \
"
-# Qt uses atomic instructions not supported in thumb mode
-ARM_INSTRUCTION_SET = "arm"
-
do_generate_qt_config_file_append() {
cat >> ${QT_CONF_PATH} <http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora 3/3] qtwebkit-examples: add RDEPENDS for ca-certificates
From: Andre McCurdy
If qtbase is configured with openssl support then the
qtwebkit browser example apps require CA certificates.
Signed-off-by: Andre McCurdy
Signed-off-by: Nicolas Dechesne
Conflicts:
recipes-qt/qt5/qtbase.inc
---
recipes-qt/qt5/qt5.inc | 2 ++
recipes-qt/qt5/qtbase.inc| 4 +++-
recipes-qt/qt5/qtwebkit-examples.inc | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/recipes-qt/qt5/qt5.inc b/recipes-qt/qt5/qt5.inc
index 7669efc..d9ebbff 100644
--- a/recipes-qt/qt5/qt5.inc
+++ b/recipes-qt/qt5/qt5.inc
@@ -7,6 +7,8 @@ inherit qmake5
ICU = "icu "
ICU_powerpc = "pango"
+PACKAGECONFIG_OPENSSL ?= "openssl"
+
QT_MODULE ?= "${BPN}"
# we don't want conflicts with qt4
diff --git a/recipes-qt/qt5/qtbase.inc b/recipes-qt/qt5/qtbase.inc
index 4f81f8e..eb22e40 100644
--- a/recipes-qt/qt5/qtbase.inc
+++ b/recipes-qt/qt5/qtbase.inc
@@ -43,6 +43,8 @@ PACKAGECONFIG_FONTS ?= ""
PACKAGECONFIG_SYSTEM ?= "jpeg libpng zlib"
PACKAGECONFIG_MULTIMEDIA ?= "${@base_contains('DISTRO_FEATURES', 'pulseaudio',
'pulseaudio', '', d)}"
PACKAGECONFIG_DISTRO ?= ""
+# This is in qt5.inc, because qtwebkit-examples are using it to enable
ca-certificates dependency
+# PACKAGECONFIG_OPENSSL ?= "openssl"
PACKAGECONFIG ??= " \
release \
@@ -50,7 +52,7 @@ PACKAGECONFIG ??= " \
udev \
evdev \
widgets \
-openssl \
+${PACKAGECONFIG_OPENSSL} \
${PACKAGECONFIG_GL} \
${PACKAGECONFIG_FB} \
${PACKAGECONFIG_X11} \
diff --git a/recipes-qt/qt5/qtwebkit-examples.inc
b/recipes-qt/qt5/qtwebkit-examples.inc
index 50c28cd..84f16a4 100644
--- a/recipes-qt/qt5/qtwebkit-examples.inc
+++ b/recipes-qt/qt5/qtwebkit-examples.inc
@@ -10,3 +10,4 @@ SRC_URI += " \
DEPENDS += "qtwebkit"
RDEPENDS_${PN}-examples += "qtwebkit-qmlplugins"
+RDEPENDS_${PN}-examples += "${@base_contains('PACKAGECONFIG_OPENSSL',
'openssl', 'ca-certificates', '', d)}"
--
1.9.0
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora 1/3] qtbase.inc: don't force ARM_INSTRUCTION_SET to arm
From: Andre McCurdy
Forcing ARM_INSTRUCTION_SET to arm when building qtbase no longer
seems to be required.
Confirmed by forcing ARM_INSTRUCTION_SET to thumb and building
qtbase 5.1.1 and 5.2.1 tuned for both armv4t and cortexa9thf-neon.
Signed-off-by: Andre McCurdy
Signed-off-by: Nicolas Dechesne
---
recipes-qt/qt5/qtbase.inc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/recipes-qt/qt5/qtbase.inc b/recipes-qt/qt5/qtbase.inc
index 71da726..e4beafd 100644
--- a/recipes-qt/qt5/qtbase.inc
+++ b/recipes-qt/qt5/qtbase.inc
@@ -130,9 +130,6 @@ QT_CONFIG_FLAGS += " \
${EXTRA_OECONF} \
"
-# Qt uses atomic instructions not supported in thumb mode
-ARM_INSTRUCTION_SET = "arm"
-
do_generate_qt_config_file_append() {
cat >> ${QT_CONF_PATH} <http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora 0/3] A couple of backport for dora
Hi Martin, the following commits were recently merged in master branch. I have rebased/backported on dora and tested on ARM board. Only 1 minor had to be resolved. Can you please merge them in dora branch? thanks nico Andre McCurdy (3): qtbase.inc: don't force ARM_INSTRUCTION_SET to arm qtbase: configure with -openssl-linked instead of -openssl qtwebkit-examples: add RDEPENDS for ca-certificates recipes-qt/qt5/qt5.inc | 2 ++ recipes-qt/qt5/qtbase.inc| 10 +- recipes-qt/qt5/qtwebkit-examples.inc | 1 + 3 files changed, 8 insertions(+), 5 deletions(-) -- 1.9.0 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH dora 2/3] qtbase: configure with -openssl-linked instead of -openssl
From: Andre McCurdy
Configure qtbase with -openssl-linked (instead of -openssl) to ensure
that run-time dependencies on libcryto and libssl are detected.
Signed-off-by: Andre McCurdy
Signed-off-by: Nicolas Dechesne
---
recipes-qt/qt5/qtbase.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/recipes-qt/qt5/qtbase.inc b/recipes-qt/qt5/qtbase.inc
index e4beafd..4f81f8e 100644
--- a/recipes-qt/qt5/qtbase.inc
+++ b/recipes-qt/qt5/qtbase.inc
@@ -114,7 +114,8 @@ PACKAGECONFIG[kms] = "-kms,-no-kms,kms"
# needed for qtdeclarative (qtdeclarative.do_configure fails to find quick
module without)
PACKAGECONFIG[icu] = "-icu,-no-icu,${ICU}"
PACKAGECONFIG[udev] = "-libudev,-no-libudev,udev"
-PACKAGECONFIG[openssl] = "-openssl,-no-openssl,openssl"
+# use -openssl-linked here to ensure that RDEPENDS for libcrypto and libssl
are detected
+PACKAGECONFIG[openssl] = "-openssl-linked,-no-openssl,openssl"
PACKAGECONFIG[alsa] = "-alsa,-no-alsa,alsa-lib"
PACKAGECONFIG[pulseaudio] = "-pulseaudio,-no-pulseaudio,pulseaudio"
PACKAGECONFIG[nis] = "-nis,-no-nis"
--
1.9.0
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH v2 2/2] qtwebkit-examples: add RDEPENDS for ca-certificates
On Mon, Feb 24, 2014 at 7:28 PM, Martin Jansa wrote: > because qtwebkit-examples is checking PACKAGECONFIG from qtbase recipe right... this is quite ugly, no? I understand what we are trying to do here. but do we really want to do it like this? is there a way we can read the qtbase PACKAGECONFIG value from within qtwebkit recipe? even if it's using some internals "sauce", that might be better than what's currently done, no? nico ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH v2 2/2] qtwebkit-examples: add RDEPENDS for ca-certificates
On Sat, Feb 22, 2014 at 9:25 AM, Martin Jansa wrote: > Please ignore my comment, I haven't noticed that you've added > PACKAGECONFIG_OPENSSL to qt5.inc and it's actually "from qtbase's > PACKAGECONFIG". > > I've added comment in qtbase.inc and integrated this to master-next. hmm. still i don't get it. openssl can be added to PACKAGECONFIG without being added in PACKAGECONFIG_OPENSSL, right? so why don't we test is openssl is in PACKAGECONFIG? Am I missing anything? nico ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5] why does Qt5 build with ARM_INSTRUCTION_SET = "arm"
hi, does anybody know why in Qt5/qtbase.inc, we have: ARM_INSTRUCTION_SET = "arm" Could it be an a low hanging fruit from the past? e.g. before https://bugreports.qt-project.org/browse/QTBUG-16402 or https://qt.gitorious.org/qt/qtbase/commit/a3bd9d4c0f3d9e80dbe35bd88649b245dca5f410? as a matter of fact, for our project Qt5 (and QtWebkit) are building (and working fine) when built with Thumb2, outside of OE. Also using ARM instruction set instead of Thumb2 enforces Webkit to use the ARM version of the javascript JIT, while the Thumb2 JIT engine seems to work a lot better in our testing... cheers nico ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH 1/2] nativesdk-qtbase: add nativesdk version of qtbase necessary for SDK tools
On Fri, Feb 7, 2014 at 2:54 AM, Denys Dmytriyenko wrote:
> 1. Make the qmake switch above at the end of do_compile instead
> 2. Keep it in do_install, but manipulate ${D} instead of ${B} by installing
> ${B}/qmake-real into ${D}/qmake
i would say #2. since the 'hack' is needed for do_install, let's keep
the dirty stuff in do_install ;-)
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH 1/2] nativesdk-qtbase: add nativesdk version of qtbase necessary for SDK tools
hi,
On Tue, Nov 26, 2013 at 2:47 AM, Denys Dmytriyenko wrote:
> +do_install() {
> +# Fix install paths for all
> +find -name "Makefile*" | xargs sed -i
> "s,(INSTALL_ROOT)${STAGING_DIR_NATIVE}${STAGING_DIR_NATIVE},(INSTALL_ROOT)${STAGING_DIR_NATIVE},g"
> +
> +# switch back the proper qmake
> +rm ${B}/bin/qmake
> +mv ${B}/bin/qmake-real ${B}/bin/qmake
> +
> +oe_runmake install INSTALL_ROOT=${D}
> +
> +# for modules which are still using syncqt and call
> qtPrepareTool(QMAKE_SYNCQT, syncqt)
> +# e.g. qt3d, qtwayland
> +ln -sf syncqt.pl ${D}${OE_QMAKE_PATH_QT_BINS}/syncqt
> +}
about this patch (which was merged already), i am wondering if this is
okay to do something like above. basically in the do_install task we
are 'corrupting' the output of the do_compile task. Here we remove
${B}/bin/qmake for example. so if the do_install fails for whatever
reason, it will never be able to resume properly, since ${B} is no
longer what it should be after a legitimate do_compile. i was
debugging some weird build issues, and I am wondering if my problem
doesn't come from that...
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Errors when using populate_sdk - has anyone encountered this before?
hi, On Thu, Jan 30, 2014 at 10:52 AM, Ridish RA wrote: > I think I got the root cause of the issue, meta-linaro that we have depends > on openembedded-core dylan-qt5.1, but Nicolas recently updated > openembedded-core to dora. And I think this is the root cause of the issue of > the relocatable patch being not able to apply? > > So do we have meta-linaro layer based openembedded-core dora? > yes, the problem is a misalignment between oe-core and meta-linaro. meta-linaro is using a recent qemu upstream commit, and the list of patches from oe-core no longer works with meta-linaro qemu_git recipe. the 2 commits in upstream qemu responsible for the misalignment are: 53db78543e473bdf7650a406767d0901c6e26480 964c6fa16f50a607f9da5068d6bf15ccc93872c0 I am cc'ing riku and koen since that needs fixing in meta-linaro (nativesdk-qemu does not build). for now, it's safe to follow Khem's suggestion and use the OE-core qemu. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] qt5 and virtualbox
Simon, On Fri, Jan 17, 2014 at 6:51 PM, Simon Busch wrote: > Thanks a lot! We're building currently three different target machines (one is > qemux86 based and for virtualbox) from the same tree and it's working very > well :) Every target has the same core system with just some changed runtime > configuration. > > If you have any questions about how to configure the setup feel free to ask :) so I was able to replicate a similar config with our distro and custom layer (Qt5 apps). that works quite well, i haven't integrated any 'input' for now, but that will be the next step. and for the record, i am using eglfs, not wayland as the backend. i noticed that you added the vboxguestdrivers in the image, however i think i am getting more or less the same behaviour whether i install them or not. what do you expect vboxvideo kernel driver to bring? cheers ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] qt5 and virtualbox
On Fri, Jan 17, 2014 at 12:52 AM, Martin Jansa wrote: > Check .bbappends in > https://github.com/webos-ports/meta-webos-ports > > there is branch also for 5.2.0 and if you check webos-ports wiki you'll > even find VirtualBox appliance build to test it without building it yourself. i could run the appliance. this is awesome stuff. pretty much exactly what i needed. we don't use the wayland QPA, but eglfs, but I don't see any specific reason why this could be a problem. this stuff is very nicely designed... a good example of what can be done with OE! ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] qt5 and virtualbox
hi there, has anyone be able to run qt5 applications in virtualbox or qemu? if so, what build configuration was used: xcb? eglfs? When running a 'desktop' distro in VirtualBox we can enable adds-on to get some support for acceleration, iirc with proper X11 video drivers. can that be used to run Qt5 application built with OE too? any detail/instructions publicly available which I might have missed? thanks nicolas ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] using OE efficiently for development
hi there, i understand the subject is a bit weird.. i am seeking for advice or best practices. how would you recommend to deploy OE in a large team of devs where it is the main 'build' engine for the entire Linux system which is *being developed*. e.g. the developers are the 'upstream' developer, but the product/system can only be built with OE. e.g. an OE build does the right thing from an 'integration' perspective (fetch from SCM, apply patches, cleanup workspace, ...) but are there any recommendations or good practices to use OE in a 'development' workflow? I am familiar with externalsrc of course, but for a very large system with 100+ recipes this isn't very practical. for the project I am referring the current/legacy workflow is: 1- checkout all source code required to build the entire system (repo, gclient, ...) 2- for any development item hack anywhere in any component 3- use a top level 'build script' 4- iterate until code ready, and push to SCM Basically, that looks like Android development workflow to illustrate even more. Now, how do we plug OE in such a workflow? any experience with concrete product development would be very much appreciated. My initial idea (not implemented, just an idea) was to create a conf file (or a layer) that has the externalsrc definition for all the recipes in the layers under development (typically all the proprietary system bits). the idea is to create a workspace such as: myproduct |- oe |- upstream and in 'oe' folder put all the recipes, and in 'upstream' all the source code under development (git clone, svn checkout, ...). the entire workspace can be checkout with repo/gclient or anything else. the externsrc variables can point to project in 'upstream' folder such that switching from 'integration' mode to 'developer' mode would require to include the conf file. i am thinking that such a 'developer' pattern must be so common, that they should be a good solution for it already. of course i am assuming that doing (large) development in WORKDIR is not very practical, and that would 'force' a large team of developers to become very familiar with the inner working of OE (task, clean, rebuild, ..). any good story to share about how OE is used in such 'developer' workflow? if we compare to the Android workflow (no troll please!) an OE workflow is more 'difficult' to grasp, i hope you see what i mean. More generally, i also curious to discuss other typical developer use case, such as developing upstream using 'feature branches', ... thanks nicolas ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] Piglit in Poky
On Wed, Jan 8, 2014 at 6:01 PM, Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > > > > On 24 December 2013 01:09, Philip Balister wrote: > > >> 1) Move piglit and deps to oe-core. Piglit is for QA purposes only > > >> and pushes the boundaries of "core platform". In a sense this is a > > >> repeat of the discussion we had with Midori... does oe-core contain > > >> everything needed to sufficiently exercise the core components it > > >> ships or not? > > > > > > I expect Richard will push back on this, and I would support him here. > > > > Probably best to let Richard speak for himself here. :) > > :) > > I have to admit I'm leaning towards pulling in the 4 recipes we need > since the win is we get to test the GL stacks. > > We do support graphics in the core, we also do particularly badly at > testing it. That is something I think we need to change. piglit lets us > do that and its not like it has a significant number of dependencies. > Having a couple more python modules to test the python stack probably > isn't a bad idea ether. We pruned quite a number of recipes out, this is > a case where we can add a small number for a significant win. I am in favor of that too. I would like to use piglit too to test GLES on some of our ARM projects. I am not sure when we can get to do it, but i am definitely interested into that, and it's been on a TODO list for some time now. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH] qtwebkit: Depend on gstreamer-1.0 instead of 0.10
On Mon, Jan 6, 2014 at 11:32 AM, Martin Jansa wrote: > > right now i am using the dora branch and qt5.1.1 which hasn't been > updated > > for a while, which is fine. > > This is only for master which will soon became just qt5.2.0 where > gstreamer-1.0 is used by default and I believe more tested than > integration with gstreamer-0.10. > > So it won't change anything for people using 5.1.1 from dora branch. If > someone really wants to use gst-0.10 with 5.2.0 I would accept patch for > PACKAGECONFIG. > Ok. thanks. I don't need it, now, at least. if we ever move to qt5.2 and still use gst0.10, then i will submit the patch > > gst-1.0* seems to be working fine for our ARM project and > we've removed all gst-0.10 from our images lately - that's why I've > noticed this qtwebkit dependency. well, assuming you get the video codec plugins ported onto gst1.0 ;-) which might not always be a trivial thing.. anyways, right now we don't have the choice and gst0.10 is required! thanks for your quick answer. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
