date:20170412

Re: [yocto] 'and' combination for OVERRIDES values?

2017-04-12 Thread Paul Eggleton

On Thursday, 13 April 2017 12:16:08 PM NZST Takashi Matsuzawa wrote:
> I just wonder if there is convenient way of defining somthing in recipes
> based on combination of two OVERRIDES variables. Say, I have two variables
> xxx and yyy.
> 
> AAA = "false"
> AAA_xxx = "true"
> AAA_yyy = "true"
> 
> But what if I want to set AAA to be "true" only when xxx and yyy are in
> OVERRIDES? (And also for 'or' condition.)

This should work for "and":

AAA_xxx_yyy = "true"

(There was a time many releases ago where this didn't, but it should work in 
any release in the last few years).

For "or" you already have the answer above, basically do it with the same 
value for both overrides:

AAA = "false"
AAA_xxx = "true"
AAA_yyy = "true"

> The similar situation for do_install_append(), etc.
> 
> do_install_append_xxx() {
> }
> 
> do_install_append_yyy() {
> }

Same thing - for and:

do_install_append_xxx_yyy() {
}

for or:

do_install_append_xxx() {
}

do_install_append_yyy() {
}

Note, we're appending here rather than setting as above, but otherwise setting 
a function is pretty much the same in terms of operations as a variable - the 
syntax is slightly different and immediate operations (such as +=) aren't 
allowed, but the same rules apply for overrides and deferred operations such 
as _append.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] 'and' combination for OVERRIDES values?

2017-04-12 Thread Takashi Matsuzawa

Hello, Yocto.

I just wonder if there is convenient way of defining somthing in recipes based 
on combination of two OVERRIDES variables.
Say, I have two variables xxx and yyy.

AAA = "false"
AAA_xxx = "true"
AAA_yyy = "true"

But what if I want to set AAA to be "true" only when xxx and yyy are in 
OVERRIDES?
(And also for 'or' condition.)

The similar situation for do_install_append(), etc.

do_install_append_xxx() {
}

do_install_append_yyy() {
}


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

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

2017-04-12 Thread Martin Kelly

On 04/12/2017 09:43 AM, Martin Kelly wrote:

On 04/12/2017 03:50 AM, Jussi Kukkonen wrote:

On 12 April 2017 at 12:54, Paul Eggleton > wrote:

On Wednesday, 12 April 2017 7:14:00 PM NZST Jussi Kukkonen wrote:
> On 11 April 2017 at 23:52, Martin Kelly > wrote:
> > I'm thinking about integrating the open-vm-tools recipe from
openswitch[1]
> > into openembedded (it massively improves the performance of
VMWare guests)
> > but first I have a question about licensing. The openswitch
repository is
> > Apache-licensed while the openembedded layers are all MIT
licensed. I'm
> > not
> > a lawyer, but my understanding is that the Apache license is a
superset of
> > the MIT license (it includes a patent clause that the MIT
license lacks),
> > and therefore MIT code can be relicensed as Apache but not the
other way
> > around.
>
> The license of the layer refers to the licensing of the recipe
files
> themselves: the source code licenses of the projects the recipes
fetch and
> build are another thing. As long as the source code license is
an open
> source one there should be no complaints about integrating into an
> openembedded layer.
>
> To be completely clear: The LICENSE variable in a recipe refers
to the
> source code license of the project to be built and should be set
based on
> the licensing info found within the version of source code that
we fetch
> and build. The recipe files are licensed according to the
LICENSE and/or
> COPYING files of the layer it is in.
>
> By the way, a quick search on layers.openembedded.org
 reveals this:
>
http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/me

>
ta-foss-openswitch/recipes-extended/open-vm-tools/open-vm-tools_10.0.5.bb

> (it seems to think the correct license is GPL).

This is muddying the waters somewhat - the LICENSE variable has
nothing to do
with this. We're only concerned with the license of the recipe
itself.

Thanks Paul: I was indeed confused and did not understand this was about
an existing recipe even though it was clearly explained in the original
post. Sorry for the noise.

Jussi

Right, I should have clarified. The underlying code is LGPLv2/GPLv2, but
the recipe file itself is Apache licensed, which is my concern.

It sounds like I should ask openswitch for relicensing first. If they
say no, we can consider the situation further.

OK, Diego Dompe, the recipe's author, is amenable to relicensing, so I 
will go ahead and do that. Thanks for the help!

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

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

2017-04-12 Thread Martin Kelly


On 04/12/2017 03:50 AM, Jussi Kukkonen wrote:



On 12 April 2017 at 12:54, Paul Eggleton > wrote:

On Wednesday, 12 April 2017 7:14:00 PM NZST Jussi Kukkonen wrote:
> On 11 April 2017 at 23:52, Martin Kelly > wrote:
> > I'm thinking about integrating the open-vm-tools recipe from 
openswitch[1]
> > into openembedded (it massively improves the performance of VMWare 
guests)
> > but first I have a question about licensing. The openswitch repository 
is
> > Apache-licensed while the openembedded layers are all MIT licensed. I'm
> > not
> > a lawyer, but my understanding is that the Apache license is a superset 
of
> > the MIT license (it includes a patent clause that the MIT license 
lacks),
> > and therefore MIT code can be relicensed as Apache but not the other way
> > around.
>
> The license of the layer refers to the licensing of the recipe files
> themselves: the source code licenses of the projects the recipes fetch and
> build are another thing. As long as the source code license is an open
> source one there should be no complaints about integrating into an
> openembedded layer.
>
> To be completely clear: The LICENSE variable in a recipe refers to the
> source code license of the project to be built and should be set based on
> the licensing info found within the version of source code that we fetch
> and build. The recipe files are licensed according to the LICENSE and/or
> COPYING files of the layer it is in.
>
> By the way, a quick search on layers.openembedded.org 
 reveals this:
> 
http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/me


> ta-foss-openswitch/recipes-extended/open-vm-tools/open-vm-tools_10.0.5.bb

> (it seems to think the correct license is GPL).

This is muddying the waters somewhat - the LICENSE variable has
nothing to do
with this. We're only concerned with the license of the recipe itself.



Thanks Paul: I was indeed confused and did not understand this was about
an existing recipe even though it was clearly explained in the original
post. Sorry for the noise.

Jussi


Right, I should have clarified. The underlying code is LGPLv2/GPLv2, but 
the recipe file itself is Apache licensed, which is my concern.


It sounds like I should ask openswitch for relicensing first. If they 
say no, we can consider the situation further.

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

[yocto] [meta-rockchip] [PATCH v2 3/3] recipes-multimedia: images: rockchip media image

2017-04-12 Thread ayaka

A image for debugging the hardware video encoder/decoder.
I also use this image for developing the Gstreamer.

Signed-off-by: ayaka 
---
 recipes-multimedia/images/rockchip-media-image.bb | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 recipes-multimedia/images/rockchip-media-image.bb

diff --git a/recipes-multimedia/images/rockchip-media-image.bb 
b/recipes-multimedia/images/rockchip-media-image.bb
new file mode 100644
index 000..ea993c1
--- /dev/null
+++ b/recipes-multimedia/images/rockchip-media-image.bb
@@ -0,0 +1,21 @@
+# Copyright (C) 2017 Randy Li 
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+include recipes-core/images/core-image-minimal.bb
+
+LICENSE = "MIT"
+DESCRIPTION = "Multimedia image for Rockchip devices."
+
+IMAGE_FEATURES_append = " package-management ssh-server-dropbear"
+IMAGE_INSTALL_append = " gdbserver gstreamer1.0-rockchip  \
+ gstreamer1.0-meta-base gstreamer1.0-meta-video gstreamer1.0-meta-audio \
+ gstreamer1.0-plugins-good-isomp4 gstreamer1.0-plugins-good-multifile \
+ gstreamer1.0-plugins-good-imagefreeze \
+ gstreamer1.0-plugins-bad-autoconvert  gstreamer1.0-plugins-bad-camerabin2 \
+ gstreamer1.0-plugins-bad-kmssink gstreamer1.0-plugins-bad-rawparse \
+ gstreamer1.0-plugins-bad-videoparsersbad \
+ gstreamer1.0-plugins-bad-mpegtsdemux \
+ gstreamer1.0-meta-debug \
+"
+
+TOOLCHAIN_HOST_TASK += "nativesdk-cmake"
-- 
2.7.4

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

[yocto] [meta-rockchip] [PATCH v2 2/3] recipes-multimedia: add gstreamer rockchip support

2017-04-12 Thread ayaka

This Gstreamer plugin provides a encoder and decoder plugin
for Gstreamer through the Rockchip MPP library.

Signed-off-by: ayaka 
---
 .../gstreamer/gstreamer1.0-rockchip.inc| 40 ++
 .../gstreamer/gstreamer1.0-rockchip_20170412.bb|  9 +
 .../gstreamer/gstreamer1.0-rockchip_git.bb | 13 +++
 3 files changed, 62 insertions(+)
 create mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-rockchip.inc
 create mode 100644 
recipes-multimedia/gstreamer/gstreamer1.0-rockchip_20170412.bb
 create mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-rockchip_git.bb

diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-rockchip.inc 
b/recipes-multimedia/gstreamer/gstreamer1.0-rockchip.inc
new file mode 100644
index 000..0bd70ab
--- /dev/null
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-rockchip.inc
@@ -0,0 +1,40 @@
+# Copyright (C) 2016 - 2017 Randy Li 
+# Released under the GNU GENERAL PUBLIC LICENSE Version 2
+# (see COPYING.GPLv2 for the terms)
+
+require recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc
+
+DESCRIPTION = "GStreamer 1.0 plugins for Rockchip platforms"
+
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=6d1e4aa87f6192354d3de840cf774d93"
+DEPENDS += "gstreamer1.0-plugins-base rockchip-mpp"
+
+SRC_URI_remove = " \
+file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
+"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+FILESPATH_prepend := "${THISDIR}/${PN}:"
+
+inherit gettext autotools pkgconfig
+
+PACKAGECONFIG ??= " \
+mpp \
+"
+PACKAGECONFIG[mpp]= 
"--enable-rockchipmpp,--disable-rockchipmpp,rockchip-mpp"
+PACKAGECONFIG[vpudec] = "--enable-vpudec,--disable-vpudec,rockchip-vpu"
+PACKAGECONFIG[drm]= 
"--enable-drmrockchip,--disable-drmrockchip,libdrm-rockchip"
+PACKAGECONFIG[egl]= "--enable-armmali,--disable-armmali,arm-mali"
+
+EXTRA_OECONF += "\
+--disable-kms\
+"
+EXTRA_OECONF_remove = "--disable-gtk-doc"
+
+do_configure[prefuncs] = " delete_pkg_m4_file"
+
+do_configure() {
+NOCONFIGURE=true ${S}/autogen.sh
+oe_runconf
+}
diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-rockchip_20170412.bb 
b/recipes-multimedia/gstreamer/gstreamer1.0-rockchip_20170412.bb
new file mode 100644
index 000..e3fecaf
--- /dev/null
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-rockchip_20170412.bb
@@ -0,0 +1,9 @@
+# Copyright (C) 2016 - 2017 Randy Li 
+# Released under the GNU GENERAL PUBLIC LICENSE Version 2
+# (see COPYING.GPLv2 for the terms)
+include gstreamer1.0-rockchip.inc
+
+TAG = "release_${PV}"
+SRC_URI = 
"git://github.com/rockchip-linux/gstreamer-rockchip.git;tag=${TAG};nobranch=1"
+
+S = "${WORKDIR}/git"
diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-rockchip_git.bb 
b/recipes-multimedia/gstreamer/gstreamer1.0-rockchip_git.bb
new file mode 100644
index 000..bd20121
--- /dev/null
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-rockchip_git.bb
@@ -0,0 +1,13 @@
+# Copyright (C) 2016 - 2017 Randy Li 
+# Released under the GNU GENERAL PUBLIC LICENSE Version 2
+# (see COPYING.GPLv2 for the terms)
+
+DEFAULT_PREFERENCE = "-1"
+
+include gstreamer1.0-rockchip.inc
+
+SRCBRANCH ?= "develop"
+SRCREV = "${AUTOREV}"
+SRC_URI = 
"git://github.com/rockchip-linux/gstreamer-rockchip.git;branch=develop"
+
+S = "${WORKDIR}/git"
-- 
2.7.4

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

[yocto] [meta-rockchip] [PATCH v2 1/3] recipes-multimedia: add Rockchip MPP library

2017-04-12 Thread ayaka

MPP means Media Process Platform. The MPP is a middleware
for the other video encoder/decoder interface, translating
the video information into the hardware registers.

Signed-off-by: ayaka 
---
 recipes-multimedia/rockchip-mpp/rockchip-mpp.inc| 21 +
 .../rockchip-mpp/rockchip-mpp_20170412.bb   |  9 +
 recipes-multimedia/rockchip-mpp/rockchip-mpp_git.bb | 16 
 3 files changed, 46 insertions(+)
 create mode 100644 recipes-multimedia/rockchip-mpp/rockchip-mpp.inc
 create mode 100644 recipes-multimedia/rockchip-mpp/rockchip-mpp_20170412.bb
 create mode 100644 recipes-multimedia/rockchip-mpp/rockchip-mpp_git.bb

diff --git a/recipes-multimedia/rockchip-mpp/rockchip-mpp.inc 
b/recipes-multimedia/rockchip-mpp/rockchip-mpp.inc
new file mode 100644
index 000..6a45637
--- /dev/null
+++ b/recipes-multimedia/rockchip-mpp/rockchip-mpp.inc
@@ -0,0 +1,21 @@
+# Copyright (C) 2016 - 2017 Randy Li 
+# Released under the GNU GENERAL PUBLIC LICENSE Version 2
+# (see COPYING.GPLv2 for the terms)
+
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = 
"file://inc/rk_mpi.h;beginline=4;endline=14;md5=acbba394ae5639b0c786f60c1f48e3d6"
+
+inherit pkgconfig cmake
+
+EXTRA_OECMAKE = " \
+-DRKPLATFORM=ON   \
+-DHAVE_DRM=ON \
+"
+
+PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN} rockchip-vpu"
+FILES_rockchip-vpu = "${libdir}/lib*vpu${SOLIBS}"
+FILES_${PN} = "${libdir}/lib*mpp${SOLIBS}"
+FILES_${PN}-dev = "${libdir}/lib*${SOLIBSDEV} ${includedir} 
${libdir}/pkgconfig"
+SECTION_${PN}-dev = "devel"
+FILES_${PN}-staticdev = "${libdir}/*.a"
+SECTION_${PN}-staticdev = "devel"
diff --git a/recipes-multimedia/rockchip-mpp/rockchip-mpp_20170412.bb 
b/recipes-multimedia/rockchip-mpp/rockchip-mpp_20170412.bb
new file mode 100644
index 000..501306a
--- /dev/null
+++ b/recipes-multimedia/rockchip-mpp/rockchip-mpp_20170412.bb
@@ -0,0 +1,9 @@
+# Copyright (C) 2016 - 2017 Randy Li 
+# Released under the GNU GENERAL PUBLIC LICENSE Version 2
+# (see COPYING.GPLv2 for the terms)
+include rockchip-mpp.inc
+
+TAG = "release_${PV}"
+SRC_URI = "git://github.com/rockchip-linux/mpp.git;tag=${TAG};nobranch=1"
+
+S = "${WORKDIR}/git"
diff --git a/recipes-multimedia/rockchip-mpp/rockchip-mpp_git.bb 
b/recipes-multimedia/rockchip-mpp/rockchip-mpp_git.bb
new file mode 100644
index 000..23f3f15
--- /dev/null
+++ b/recipes-multimedia/rockchip-mpp/rockchip-mpp_git.bb
@@ -0,0 +1,16 @@
+# Copyright (C) 2016 - 2017 Randy Li 
+# Released under the GNU GENERAL PUBLIC LICENSE Version 2
+# (see COPYING.GPLv2 for the terms)
+
+DEFAULT_PREFERENCE = "-1"
+
+include rockchip-mpp.inc
+DEPENDS = "git-replacement-native"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+FILESPATH_prepend := "${THISDIR}/${PN}:"
+
+SRCREV = "${AUTOREV}"
+SRC_URI = "git://github.com/rockchip-linux/mpp.git;branch=develop"
+
+S = "${WORKDIR}/git"
-- 
2.7.4

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

[yocto] [meta-rockchip] [PATCH v2 0/3] Add video codec recipes

2017-04-12 Thread ayaka

Those packages are the userspace libraries for the Rockchip
Android video codec driver.

Also a minimal image used for verified the media framework is included.

ayaka (3):
  recipes-multimedia: add Rockchip MPP library
  recipes-multimedia: add gstreamer rockchip support
  recipes-multimedia: images: rockchip media image

 .../gstreamer/gstreamer1.0-rockchip.inc| 40 ++
 .../gstreamer/gstreamer1.0-rockchip_20170412.bb|  9 +
 .../gstreamer/gstreamer1.0-rockchip_git.bb | 13 +++
 recipes-multimedia/images/rockchip-media-image.bb  | 21 
 recipes-multimedia/rockchip-mpp/rockchip-mpp.inc   | 21 
 .../rockchip-mpp/rockchip-mpp_20170412.bb  |  9 +
 .../rockchip-mpp/rockchip-mpp_git.bb   | 16 +
 7 files changed, 129 insertions(+)
 create mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-rockchip.inc
 create mode 100644 
recipes-multimedia/gstreamer/gstreamer1.0-rockchip_20170412.bb
 create mode 100644 recipes-multimedia/gstreamer/gstreamer1.0-rockchip_git.bb
 create mode 100644 recipes-multimedia/images/rockchip-media-image.bb
 create mode 100644 recipes-multimedia/rockchip-mpp/rockchip-mpp.inc
 create mode 100644 recipes-multimedia/rockchip-mpp/rockchip-mpp_20170412.bb
 create mode 100644 recipes-multimedia/rockchip-mpp/rockchip-mpp_git.bb

-- 
2.7.4

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

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

2017-04-12 Thread Jussi Kukkonen

On 12 April 2017 at 12:54, Paul Eggleton 
wrote:

> On Wednesday, 12 April 2017 7:14:00 PM NZST Jussi Kukkonen wrote:
> > On 11 April 2017 at 23:52, Martin Kelly  wrote:
> > > I'm thinking about integrating the open-vm-tools recipe from
> openswitch[1]
> > > into openembedded (it massively improves the performance of VMWare
> guests)
> > > but first I have a question about licensing. The openswitch repository
> is
> > > Apache-licensed while the openembedded layers are all MIT licensed. I'm
> > > not
> > > a lawyer, but my understanding is that the Apache license is a
> superset of
> > > the MIT license (it includes a patent clause that the MIT license
> lacks),
> > > and therefore MIT code can be relicensed as Apache but not the other
> way
> > > around.
> >
> > The license of the layer refers to the licensing of the recipe files
> > themselves: the source code licenses of the projects the recipes fetch
> and
> > build are another thing. As long as the source code license is an open
> > source one there should be no complaints about integrating into an
> > openembedded layer.
> >
> > To be completely clear: The LICENSE variable in a recipe refers to the
> > source code license of the project to be built and should be set based on
> > the licensing info found within the version of source code that we fetch
> > and build. The recipe files are licensed according to the LICENSE and/or
> > COPYING files of the layer it is in.
> >
> > By the way, a quick search on layers.openembedded.org reveals this:
> > http://git.openswitch.net/cgit/openswitch/ops-build/
> tree/yocto/openswitch/me
> > ta-foss-openswitch/recipes-extended/open-vm-tools/open-
> vm-tools_10.0.5.bb
> > (it seems to think the correct license is GPL).
>
> This is muddying the waters somewhat - the LICENSE variable has nothing to
> do
> with this. We're only concerned with the license of the recipe itself.
>


Thanks Paul: I was indeed confused and did not understand this was about an
existing recipe even though it was clearly explained in the original post.
Sorry for the noise.

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

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

2017-04-12 Thread Paul Eggleton

On Wednesday, 12 April 2017 7:14:00 PM NZST Jussi Kukkonen wrote:
> On 11 April 2017 at 23:52, Martin Kelly  wrote:
> > I'm thinking about integrating the open-vm-tools recipe from openswitch[1]
> > into openembedded (it massively improves the performance of VMWare guests)
> > but first I have a question about licensing. The openswitch repository is
> > Apache-licensed while the openembedded layers are all MIT licensed. I'm
> > not
> > a lawyer, but my understanding is that the Apache license is a superset of
> > the MIT license (it includes a patent clause that the MIT license lacks),
> > and therefore MIT code can be relicensed as Apache but not the other way
> > around.
> 
> The license of the layer refers to the licensing of the recipe files
> themselves: the source code licenses of the projects the recipes fetch and
> build are another thing. As long as the source code license is an open
> source one there should be no complaints about integrating into an
> openembedded layer.
> 
> To be completely clear: The LICENSE variable in a recipe refers to the
> source code license of the project to be built and should be set based on
> the licensing info found within the version of source code that we fetch
> and build. The recipe files are licensed according to the LICENSE and/or
> COPYING files of the layer it is in.
> 
> By the way, a quick search on layers.openembedded.org reveals this:
> http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/me
> ta-foss-openswitch/recipes-extended/open-vm-tools/open-vm-tools_10.0.5.bb
> (it seems to think the correct license is GPL).

This is muddying the waters somewhat - the LICENSE variable has nothing to do 
with this. We're only concerned with the license of the recipe itself.

My person opinion on the original question is that we shouldn't complicate 
matters by adding more than one license for metadata within the same layer if 
it's avoidable, so my suggestion would be to ask the original authors if they 
would be willing to relicense the single recipe you wish to copy as MIT.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] multiconfig samples not put in the build dir.

2017-04-12 Thread Paulo Neves

>Not really my call to make.  Also, please keep this discussion on the
>mailing list so that everyone benefits.

Sorry forgot to hit the reply all. Thanks for the suggestion I am now
waiting input from the rest of the community regarding the
applicability of rename command.

On Wed, Apr 12, 2017 at 9:28 AM, Gary Thomas  wrote:
> On 2017-04-12 09:15, Paulo Neves wrote:
>>
>> Hello Gary.
>>
>> I didn't know it was not a coreutil. To do it in another way i think
>> this simple code will grow. Before refactoring could I have other
>> opinions?
>>
>> We have a very limited environment and even so the rename exists. It
>> is part of the util-linux-ng from the kernel...
>
>
> Not really my call to make.  Also, please keep this discussion on the
> mailing list so that everyone benefits.
>
>> On Wed, Apr 12, 2017 at 9:10 AM, Gary Thomas  wrote:
>>>
>>> On 2017-04-12 09:02, Paulo Neves wrote:


 I expect it to rename all the .conf.sample files from .conf.sample to
 .conf. Give it a try ;)
>>>
>>>
>>>
>>> This introduces a new dependency for the rename tool/program which is
>>> a Perl script.  It seems to me that much effort has been made recently
>>> to minimize these scripts, removing bash-isms, etc, and adding this
>>> dependency would drift from that path.
>>>
>>> Just my 2c
>>>

 On Wed, Apr 12, 2017 at 8:54 AM, Gary Thomas  wrote:
>
>
> On 2017-04-12 08:48, Paulo Neves wrote:
>>
>>
>>
>> Hello,
>>
>> I thought it would be consistent to have the multiconfig samples to
>> also be populated just like the local.conf.
>>
>> I produced a patch accordingly:
>>
>>> From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00
>>> 2001
>>
>>
>>
>> From: Paulo Neves 
>> Date: Mon, 3 Apr 2017 11:23:12 +0200
>> Subject: [PATCH 1/2] multiconfig samples are now put in the build dir.
>>
>> The users of multiconfig which use the templateconf
>> mechanism may also want the multiconfig samples to
>> be retrieved from the template configuration
>> directories. This patch allows for that.
>>
>> It only copies the .conf.sample files. It does not
>> create the multiconfig directory if the templateconf
>> directory does not exist or have any sample files.
>> ---
>>  scripts/oe-setup-builddir | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
>> index
>>
>>
>> ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610
>> 100755
>> --- a/scripts/oe-setup-builddir
>> +++ b/scripts/oe-setup-builddir
>> @@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then
>>  OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
>>  OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"
>>  fi
>> -
>>  unset SHOWYPDOC
>>  if [ -z "$OECORELOCALCONF" ]; then
>>  OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample"
>>  fi
>> +
>>  if [ ! -r "$BUILDDIR/conf/local.conf" ]; then
>>  cat <>  You had no conf/local.conf file. This configuration file has
>> therefore
>> been
>> @@ -91,12 +91,20 @@ for more information as common configuration
>> options are commented.
>>
>>  EOM
>>  cp -f $OECORELOCALCONF "$BUILDDIR/conf/local.conf"
>> +if ( find "$TEMPLATECONF/multiconfig/" -iname '*.conf.sample'
>> 2>&1 >  /dev/null ); then
>> +   mkdir -p "$BUILDDIR/conf/multiconfig/"
>> +cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/"
>> +(cd "$BUILDDIR/conf/multiconfig/" &&
>> +rename .conf.sample .conf *.conf.sample)
>
>
>
>
> This doesn't look right to me - what are you expecting the 'rename'
> command
> to do?
>
>> +echo "Multiconfig samples detected copying them also.\n"
>> +fi
>>  SHOWYPDOC=yes
>>  fi
>>
>>  if [ -z "$OECORELAYERCONF" ]; then
>>  OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample"
>>  fi
>> +
>>  if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then
>>  cat <>  You had no conf/bblayers.conf file. This configuration file has
>> therefore
>> been
>
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] multiconfig samples not put in the build dir.

2017-04-12 Thread Gary Thomas


On 2017-04-12 09:15, Paulo Neves wrote:

Hello Gary.

I didn't know it was not a coreutil. To do it in another way i think
this simple code will grow. Before refactoring could I have other
opinions?

We have a very limited environment and even so the rename exists. It
is part of the util-linux-ng from the kernel...


Not really my call to make.  Also, please keep this discussion on the
mailing list so that everyone benefits.


On Wed, Apr 12, 2017 at 9:10 AM, Gary Thomas  wrote:

On 2017-04-12 09:02, Paulo Neves wrote:


I expect it to rename all the .conf.sample files from .conf.sample to
.conf. Give it a try ;)



This introduces a new dependency for the rename tool/program which is
a Perl script.  It seems to me that much effort has been made recently
to minimize these scripts, removing bash-isms, etc, and adding this
dependency would drift from that path.

Just my 2c



On Wed, Apr 12, 2017 at 8:54 AM, Gary Thomas  wrote:


On 2017-04-12 08:48, Paulo Neves wrote:



Hello,

I thought it would be consistent to have the multiconfig samples to
also be populated just like the local.conf.

I produced a patch accordingly:


From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001



From: Paulo Neves 
Date: Mon, 3 Apr 2017 11:23:12 +0200
Subject: [PATCH 1/2] multiconfig samples are now put in the build dir.

The users of multiconfig which use the templateconf
mechanism may also want the multiconfig samples to
be retrieved from the template configuration
directories. This patch allows for that.

It only copies the .conf.sample files. It does not
create the multiconfig directory if the templateconf
directory does not exist or have any sample files.
---
 scripts/oe-setup-builddir | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index

ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610
100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then
 OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
 OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"
 fi
-
 unset SHOWYPDOC
 if [ -z "$OECORELOCALCONF" ]; then
 OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/local.conf" ]; then
 cat <&1 >  /dev/null ); then
+   mkdir -p "$BUILDDIR/conf/multiconfig/"
+cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/"
+(cd "$BUILDDIR/conf/multiconfig/" &&
+rename .conf.sample .conf *.conf.sample)




This doesn't look right to me - what are you expecting the 'rename'
command
to do?


+echo "Multiconfig samples detected copying them also.\n"
+fi
 SHOWYPDOC=yes
 fi

 if [ -z "$OECORELAYERCONF" ]; then
 OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then
 cat <

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

2017-04-12 Thread Jussi Kukkonen

On 11 April 2017 at 23:52, Martin Kelly  wrote:

> Hi,
>
> I'm thinking about integrating the open-vm-tools recipe from openswitch[1]
> into openembedded (it massively improves the performance of VMWare guests)
> but first I have a question about licensing. The openswitch repository is
> Apache-licensed while the openembedded layers are all MIT licensed. I'm not
> a lawyer, but my understanding is that the Apache license is a superset of
> the MIT license (it includes a patent clause that the MIT license lacks),
> and therefore MIT code can be relicensed as Apache but not the other way
> around.
>

The license of the layer refers to the licensing of the recipe files
themselves: the source code licenses of the projects the recipes fetch and
build are another thing. As long as the source code license is an open
source one there should be no complaints about integrating into an
openembedded layer.

To be completely clear: The LICENSE variable in a recipe refers to the
source code license of the project to be built and should be set based on
the licensing info found within the version of source code that we fetch
and build. The recipe files are licensed according to the LICENSE and/or
COPYING files of the layer it is in.

By the way, a quick search on layers.openembedded.org reveals this:
http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/meta-foss-openswitch/recipes-extended/open-vm-tools/open-vm-tools_10.0.5.bb
(it seems to think the correct license is GPL).

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

Re: [yocto] multiconfig samples not put in the build dir.

2017-04-12 Thread Gary Thomas


On 2017-04-12 09:02, Paulo Neves wrote:

I expect it to rename all the .conf.sample files from .conf.sample to
.conf. Give it a try ;)


This introduces a new dependency for the rename tool/program which is
a Perl script.  It seems to me that much effort has been made recently
to minimize these scripts, removing bash-isms, etc, and adding this
dependency would drift from that path.

Just my 2c



On Wed, Apr 12, 2017 at 8:54 AM, Gary Thomas  wrote:

On 2017-04-12 08:48, Paulo Neves wrote:


Hello,

I thought it would be consistent to have the multiconfig samples to
also be populated just like the local.conf.

I produced a patch accordingly:


From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001


From: Paulo Neves 
Date: Mon, 3 Apr 2017 11:23:12 +0200
Subject: [PATCH 1/2] multiconfig samples are now put in the build dir.

The users of multiconfig which use the templateconf
mechanism may also want the multiconfig samples to
be retrieved from the template configuration
directories. This patch allows for that.

It only copies the .conf.sample files. It does not
create the multiconfig directory if the templateconf
directory does not exist or have any sample files.
---
 scripts/oe-setup-builddir | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index
ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610
100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then
 OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
 OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"
 fi
-
 unset SHOWYPDOC
 if [ -z "$OECORELOCALCONF" ]; then
 OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/local.conf" ]; then
 cat <&1 >  /dev/null ); then
+   mkdir -p "$BUILDDIR/conf/multiconfig/"
+cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/"
+(cd "$BUILDDIR/conf/multiconfig/" &&
+rename .conf.sample .conf *.conf.sample)



This doesn't look right to me - what are you expecting the 'rename' command
to do?


+echo "Multiconfig samples detected copying them also.\n"
+fi
 SHOWYPDOC=yes
 fi

 if [ -z "$OECORELAYERCONF" ]; then
 OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then
 cat <

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] multiconfig samples not put in the build dir.

2017-04-12 Thread Paulo Neves

I expect it to rename all the .conf.sample files from .conf.sample to
.conf. Give it a try ;)

On Wed, Apr 12, 2017 at 8:54 AM, Gary Thomas  wrote:
> On 2017-04-12 08:48, Paulo Neves wrote:
>>
>> Hello,
>>
>> I thought it would be consistent to have the multiconfig samples to
>> also be populated just like the local.conf.
>>
>> I produced a patch accordingly:
>>
>>> From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001
>>
>> From: Paulo Neves 
>> Date: Mon, 3 Apr 2017 11:23:12 +0200
>> Subject: [PATCH 1/2] multiconfig samples are now put in the build dir.
>>
>> The users of multiconfig which use the templateconf
>> mechanism may also want the multiconfig samples to
>> be retrieved from the template configuration
>> directories. This patch allows for that.
>>
>> It only copies the .conf.sample files. It does not
>> create the multiconfig directory if the templateconf
>> directory does not exist or have any sample files.
>> ---
>>  scripts/oe-setup-builddir | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
>> index
>> ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610
>> 100755
>> --- a/scripts/oe-setup-builddir
>> +++ b/scripts/oe-setup-builddir
>> @@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then
>>  OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
>>  OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"
>>  fi
>> -
>>  unset SHOWYPDOC
>>  if [ -z "$OECORELOCALCONF" ]; then
>>  OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample"
>>  fi
>> +
>>  if [ ! -r "$BUILDDIR/conf/local.conf" ]; then
>>  cat <>  You had no conf/local.conf file. This configuration file has therefore
>> been
>> @@ -91,12 +91,20 @@ for more information as common configuration
>> options are commented.
>>
>>  EOM
>>  cp -f $OECORELOCALCONF "$BUILDDIR/conf/local.conf"
>> +if ( find "$TEMPLATECONF/multiconfig/" -iname '*.conf.sample'
>> 2>&1 >  /dev/null ); then
>> +   mkdir -p "$BUILDDIR/conf/multiconfig/"
>> +cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/"
>> +(cd "$BUILDDIR/conf/multiconfig/" &&
>> +rename .conf.sample .conf *.conf.sample)
>
>
> This doesn't look right to me - what are you expecting the 'rename' command
> to do?
>
>> +echo "Multiconfig samples detected copying them also.\n"
>> +fi
>>  SHOWYPDOC=yes
>>  fi
>>
>>  if [ -z "$OECORELAYERCONF" ]; then
>>  OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample"
>>  fi
>> +
>>  if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then
>>  cat <>  You had no conf/bblayers.conf file. This configuration file has therefore
>> been
>>
>
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] multiconfig samples not put in the build dir.

2017-04-12 Thread Gary Thomas


On 2017-04-12 08:48, Paulo Neves wrote:

Hello,

I thought it would be consistent to have the multiconfig samples to
also be populated just like the local.conf.

I produced a patch accordingly:


From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001

From: Paulo Neves 
Date: Mon, 3 Apr 2017 11:23:12 +0200
Subject: [PATCH 1/2] multiconfig samples are now put in the build dir.

The users of multiconfig which use the templateconf
mechanism may also want the multiconfig samples to
be retrieved from the template configuration
directories. This patch allows for that.

It only copies the .conf.sample files. It does not
create the multiconfig directory if the templateconf
directory does not exist or have any sample files.
---
 scripts/oe-setup-builddir | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index 
ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610
100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then
 OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
 OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"
 fi
-
 unset SHOWYPDOC
 if [ -z "$OECORELOCALCONF" ]; then
 OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/local.conf" ]; then
 cat <&1 >  /dev/null ); then
+   mkdir -p "$BUILDDIR/conf/multiconfig/"
+cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/"
+(cd "$BUILDDIR/conf/multiconfig/" &&
+rename .conf.sample .conf *.conf.sample)


This doesn't look right to me - what are you expecting the 'rename' command to 
do?


+echo "Multiconfig samples detected copying them also.\n"
+fi
 SHOWYPDOC=yes
 fi

 if [ -z "$OECORELAYERCONF" ]; then
 OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then
 cat <


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] multiconfig samples not put in the build dir.

2017-04-12 Thread Paulo Neves

Hello,

I thought it would be consistent to have the multiconfig samples to
also be populated just like the local.conf.

I produced a patch accordingly:

>From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001
From: Paulo Neves 
Date: Mon, 3 Apr 2017 11:23:12 +0200
Subject: [PATCH 1/2] multiconfig samples are now put in the build dir.

The users of multiconfig which use the templateconf
mechanism may also want the multiconfig samples to
be retrieved from the template configuration
directories. This patch allows for that.

It only copies the .conf.sample files. It does not
create the multiconfig directory if the templateconf
directory does not exist or have any sample files.
---
 scripts/oe-setup-builddir | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index 
ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610
100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then
 OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
 OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"
 fi
-
 unset SHOWYPDOC
 if [ -z "$OECORELOCALCONF" ]; then
 OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/local.conf" ]; then
 cat <&1 >  /dev/null ); then
+   mkdir -p "$BUILDDIR/conf/multiconfig/"
+cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/"
+(cd "$BUILDDIR/conf/multiconfig/" &&
+rename .conf.sample .conf *.conf.sample)
+echo "Multiconfig samples detected copying them also.\n"
+fi
 SHOWYPDOC=yes
 fi

 if [ -z "$OECORELAYERCONF" ]; then
 OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then
 cat

[yocto] Bug 11307 - sstate.bbclass tries to modify mirror files

2017-04-12 Thread Paulo Neves

Commit 51edde653707e7a3cd2186082458f01f32cd1996 makes a wrong
assumption that SSTATE_MIRRORS have write permissions.

A mirror is by definition outside of it's user control. In my use case
it happens I does not have permissions to update the access time of
the dereferenced symbolic-link file.

If we had the possibility to modify the sstate-mirror we would have
set SSTATE_DIR instead. There are 3 possible fixes:

* Revert this patch. It seems tailored to a very special use case
which breaks the definition of mirror.
* Only touch the file if the file access time is writeable.
* Set (yet) another option to touch SSTATE_MIRROR files.

I also can imagine this raising sever performance issues if the mirror
is used by several users at the same time. The server will need to
update the file meta data every time

This patch fixes the bug with minimal impact on the original
functionality. Option 2


Related to (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10857)

>From aa8cab9660744c8d5277f8e82f10a844884aff78 Mon Sep 17 00:00:00 2001
From: Paulo Neves 
Date: Tue, 11 Apr 2017 10:57:47 +0300
Subject: [PATCH] Added test for write ability of sstate-mirror .siginfo

---
 meta/classes/sstate.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 
af588548c2ef85d966787df7ae1432e1744bdba6..36cbbd151aa1c93f4ca377b3a23c011a527389d8
100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -753,7 +753,7 @@ python sstate_sign_package () {
 sstate_unpack_package () {
  tar -xvzf ${SSTATE_PKG}
  # update .siginfo atime on local/NFS mirror
- [ -h ${SSTATE_PKG}.siginfo ] && touch -a ${SSTATE_PKG}.siginfo
+ [ -w ${SSTATE_PKG}.siginfo ] && [ -h ${SSTATE_PKG}.siginfo ] &&
touch -a ${SSTATE_PKG}.siginfo
  # Use "! -w ||" to return true for read only files
  [ ! -w ${SSTATE_PKG} ] || touch --no-dereference ${SSTATE_PKG}
  [ ! -w ${SSTATE_PKG}.sig ] || [ ! -e ${SSTATE_PKG}.sig ] || touch
--no-dereference ${SSTATE_PKG}.sig
-- 
2.6.2



Best regards
Paulo Neves
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] 'and' combination for OVERRIDES values?

[yocto] 'and' combination for OVERRIDES values?

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

[yocto] [meta-rockchip] [PATCH v2 3/3] recipes-multimedia: images: rockchip media image

[yocto] [meta-rockchip] [PATCH v2 2/3] recipes-multimedia: add gstreamer rockchip support

[yocto] [meta-rockchip] [PATCH v2 1/3] recipes-multimedia: add Rockchip MPP library

[yocto] [meta-rockchip] [PATCH v2 0/3] Add video codec recipes

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

Re: [yocto] multiconfig samples not put in the build dir.

Re: [yocto] multiconfig samples not put in the build dir.

Re: [yocto] Relicensing an Apache-licensed recipe as MIT

Re: [yocto] multiconfig samples not put in the build dir.

Re: [yocto] multiconfig samples not put in the build dir.

Re: [yocto] multiconfig samples not put in the build dir.

[yocto] multiconfig samples not put in the build dir.

[yocto] Bug 11307 - sstate.bbclass tries to modify mirror files

18 matches

Site Navigation

Mail list logo

Footer information