[OE-core] Fwd: [PATCH] recipes-support: Add recipe for libgpiod

[Belisko Marek]

libgpiod - C library and tools for interacting with the linux GPIO
character device

Since linux 4.8 the GPIO sysfs interface is deprecated.
User space should use the character device instead.
This library encapsulates the ioctl calls and data structures behind a
straightforward API.

Signed-off-by: Marek Belisko 
---
 meta/recipes-support/libgpiod/libgpiod_0.2.bb | 25 +
 1 file changed, 25 insertions(+)
 create mode 100644 meta/recipes-support/libgpiod/libgpiod_0.2.bb

diff --git a/meta/recipes-support/libgpiod/libgpiod_0.2.bb
b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
new file mode 100644
index 000..fe2cd80
--- /dev/null
+++ b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
@@ -0,0 +1,25 @@
+SUMMARY = "C library and tools for interacting with the linux GPIO
character device"
+HOMEPAGE = "https://github.com/brgl/libgpiod";
+
+LICENSE = "LGPLv2.1+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=2caced0b25dfefd4c601d92bd15116de"
+
+UPSTREAM_CHECK_URI = "https://github.com/brgl/libgpiod/releases";
+
+SRC_URI = "https://github.com/brgl/libgpiod/archive/v${PV}.tar.gz";
+
+SRC_URI[md5sum] = "e3430f35b6efa842693d659c0bfb7ad5"
+SRC_URI[sha256sum] =
"de1947f3cb2cc4174364af430309fe6238976658575655bdbd76c60cffa7df92"
+
+inherit autotools pkgconfig
+
+# enable tools
+PACKAGECONFIG ?= "tools"
+
+PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,kmod udev"
+PACKAGECONFIG[tools] = "--enable-tools,--disable-tools,"
+
+PACKAGES += " ${PN}-tools"
+
+FILES_${PN} = "${libdir}/*"
+FILES_${PN}-tools = "${bindir}/*"
--
2.7.4
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] icu: Use LARGE_BUFFER_MAX_SIZE for cmd

[jackie.huang]

From: Jackie Huang 

The previous patch used LARGE_BUFFER_MAX_SIZE instead
of SMALL_BUFFER_MAX_SIZE for cmd in function pkg_installLibrary,
which only fixed some of the cases when the command line
is too long, some other cases indicate that the
LARGE_BUFFER_MAX_SIZE is also needed in pkg_installCommonMode
and pkg_installFileMode to avoid overflow:

| *** buffer overflow detected ***: ../bin/pkgdata terminated

Signed-off-by: Jackie Huang 
---
 .../icu/icu/icu-pkgdata-large-cmd.patch| 28 ++
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-support/icu/icu/icu-pkgdata-large-cmd.patch 
b/meta/recipes-support/icu/icu/icu-pkgdata-large-cmd.patch
index 6e40659227f..e758a623ef4 100644
--- a/meta/recipes-support/icu/icu/icu-pkgdata-large-cmd.patch
+++ b/meta/recipes-support/icu/icu/icu-pkgdata-large-cmd.patch
@@ -8,14 +8,16 @@ LARGE_BUFFER_MAX_SIZE.
 Upstream-Status: Pending
 
 Signed-off-by: Robert Yang 
+Signed-off-by: Jackie Huang 
 ---
- tools/pkgdata/pkgdata.cpp |2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
+ tools/pkgdata/pkgdata.cpp | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/tools/pkgdata/pkgdata.cpp b/tools/pkgdata/pkgdata.cpp
+index 60167dd..506dd32 100644
 --- a/tools/pkgdata/pkgdata.cpp
 +++ b/tools/pkgdata/pkgdata.cpp
-@@ -1019,7 +1019,7 @@ normal_symlink_mode:
+@@ -1084,7 +1084,7 @@ normal_symlink_mode:
  
  static int32_t pkg_installLibrary(const char *installDir, const char 
*targetDir, UBool noVersion) {
  int32_t result = 0;
@@ -24,6 +26,24 @@ diff --git a/tools/pkgdata/pkgdata.cpp 
b/tools/pkgdata/pkgdata.cpp
  
  sprintf(cmd, "cd %s && %s %s %s%s%s",
  targetDir,
+@@ -1152,7 +1152,7 @@ static int32_t pkg_installLibrary(const char 
*installDir, const char *targetDir,
+ 
+ static int32_t pkg_installCommonMode(const char *installDir, const char 
*fileName) {
+ int32_t result = 0;
+-char cmd[SMALL_BUFFER_MAX_SIZE] = "";
++char cmd[LARGE_BUFFER_MAX_SIZE] = "";
+ 
+ if (!T_FileStream_file_exists(installDir)) {
+ UErrorCode status = U_ZERO_ERROR;
+@@ -1184,7 +1184,7 @@ static int32_t pkg_installCommonMode(const char 
*installDir, const char *fileNam
+ #endif
+ static int32_t pkg_installFileMode(const char *installDir, const char 
*srcDir, const char *fileListName) {
+ int32_t result = 0;
+-char cmd[SMALL_BUFFER_MAX_SIZE] = "";
++char cmd[LARGE_BUFFER_MAX_SIZE] = "";
+ 
+ if (!T_FileStream_file_exists(installDir)) {
+ UErrorCode status = U_ZERO_ERROR;
 -- 
-1.7.10.4
+1.9.1
 
-- 
2.11.0

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

Re: [OE-core] GUI based images

[Philip Balister]

On 05/09/2017 03:03 PM, Paul Eggleton wrote:
> On Wednesday, 10 May 2017 8:39:58 AM NZST Alexander Kanavin wrote:
>> On 05/09/2017 11:19 PM, Khem Raj wrote:
>>> I think we should always intend to align the reference stack with
>>> whats commonly used in
>>> userbases we target to address with project, we will not be serving
>>> the project goals and its username if we
>>> trim down to packages which are just used for reference, if majority of
>>> the community we intend to address uses QT or any other stack for that
>>> matter then we should align our requirements accordingly which will be
>>> mutually beneficial IMO
>>
>> I strongly disagree. Oe-core is not a Greatest Embedded Hits collection 
>> or any kind of 'reference stack', and decisions on what goes into it 
>> should not be based on how popular it is. 
> 
> A number of things have been added to OE-Core because they are widely used, 
> so 
> I don't think that's true. However, that doesn't mean that would be used as a 
> justification to add Qt5. I'm not even convinced we would need to add Qt5 to 
> OE-Core in order to use it as part of a reference UI - the key requirement 
> would be for us to commit to being part of its testing and maintenance, 
> everything else is just logistics.
> 
>> If you do this, you risk overextending the layer, and ending up not doing a
>> particularly good job on any of the things it tries to do. It's best to
>> allow other layers to  flourish, let the domain specialists do their job and
>> decide for themselves how they want to do things, and have a curated list of
>> layers that are known to be high quality and approved by Yocto Project.
>>
>> If you want qt5, use meta-qt5 and meta-b2qt, both made by people who 
>> actually develop the Qt stack itself. End of story.
> 
> Your opinion is noted. My opinion is that we ought to be providing a good 
> reference that can be used as a basis for real products (regardless of 
> whether 
> whatever direction we choose to go is Qt-based or not) - the rest of our 
> stack 
> *is* used that way, after all. We regularly get comments about how Sato isn't 
> suitable as such a basis, so the expectation is there. I don't think adding 
> Wayland support alone will answer that.

Does anyone currently ship a real product based on sato?

Yes, I am aware that sato works for testing gui stuff, just trying to
understand if it is used beyond that.

Philip

> 
> Cheers,
> Paul
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tcmode-default: use SDK_SYS suffix instead of SDK_ARCH for binutils-crosssdk

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

Commit d2eb70e809d482c493922f23aef4409cfd82 has changed suffixes for
all -crosssdk packages from SDK_ARCH to SDK_SYS, but missed one line with
binutils-crosssdk. This change fixes that omission.

Signed-off-by: Denys Dmytriyenko 
---
 meta/conf/distro/include/tcmode-default.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index 3db16e8..bdc70cf 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -48,7 +48,7 @@ PREFERRED_VERSION_nativesdk-libgcc-initial ?= 
"${SDKGCCVERSION}"
 PREFERRED_VERSION_binutils ?= "${BINUVERSION}"
 PREFERRED_VERSION_binutils-native ?= "${BINUVERSION}"
 PREFERRED_VERSION_binutils-cross-${TARGET_ARCH} ?= "${BINUVERSION}"
-PREFERRED_VERSION_binutils-crosssdk-${SDK_ARCH} ?= "${BINUVERSION}"
+PREFERRED_VERSION_binutils-crosssdk-${SDK_SYS} ?= "${BINUVERSION}"
 PREFERRED_VERSION_binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} ?= 
"${BINUVERSION}"
 PREFERRED_VERSION_gdb ?= "${GDBVERSION}"
 PREFERRED_VERSION_gdb-cross-${TARGET_ARCH} ?= "${GDBVERSION}"
-- 
2.7.4

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

Re: [OE-core] [yocto] [PATCH] recipes-support: Add recipe for libgpiod

[Denys Dmytriyenko]

Can libsoc help here? It's in meta-oe, but this libgpiod should be there too...

On Tue, May 09, 2017 at 02:24:18PM -0700, akuster808 wrote:
> Marek,
> 
> There is another mailing list that is geared towards the core
> development and recipes like this that are targeted for the main
> "meta" layer.
> 
> You should resend this patch to: openembedded-core@lists.openembedded.org.
> 
> regards,
> 
> Armin
> 
> 
> On 05/09/2017 02:10 PM, Marek Belisko wrote:
> >libgpiod - C library and tools for interacting with the linux GPIO
> >character device
> >
> >Since linux 4.8 the GPIO sysfs interface is deprecated.
> >User space should use the character device instead.
> >This library encapsulates the ioctl calls and data structures behind a
> >straightforward API.
> >
> >Signed-off-by: Marek Belisko 
> >---
> >  meta/recipes-support/libgpiod/libgpiod_0.2.bb | 25 
> > +
> >  1 file changed, 25 insertions(+)
> >  create mode 100644 meta/recipes-support/libgpiod/libgpiod_0.2.bb
> >
> >diff --git a/meta/recipes-support/libgpiod/libgpiod_0.2.bb 
> >b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
> >new file mode 100644
> >index 000..fe2cd80
> >--- /dev/null
> >+++ b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
> >@@ -0,0 +1,25 @@
> >+SUMMARY = "C library and tools for interacting with the linux GPIO 
> >character device"
> >+HOMEPAGE = "https://github.com/brgl/libgpiod";
> >+
> >+LICENSE = "LGPLv2.1+"
> >+LIC_FILES_CHKSUM = "file://COPYING;md5=2caced0b25dfefd4c601d92bd15116de"
> >+
> >+UPSTREAM_CHECK_URI = "https://github.com/brgl/libgpiod/releases";
> >+
> >+SRC_URI = "https://github.com/brgl/libgpiod/archive/v${PV}.tar.gz";
> >+
> >+SRC_URI[md5sum] = "e3430f35b6efa842693d659c0bfb7ad5"
> >+SRC_URI[sha256sum] = 
> >"de1947f3cb2cc4174364af430309fe6238976658575655bdbd76c60cffa7df92"
> >+
> >+inherit autotools pkgconfig
> >+
> >+# enable tools
> >+PACKAGECONFIG ?= "tools"
> >+
> >+PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,kmod udev"
> >+PACKAGECONFIG[tools] = "--enable-tools,--disable-tools,"
> >+
> >+PACKAGES += " ${PN}-tools"
> >+
> >+FILES_${PN} = "${libdir}/*"
> >+FILES_${PN}-tools = "${bindir}/*"
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] [PATCH] recipes-support: Add recipe for libgpiod

[akuster808]

Marek,

There is another mailing list that is geared towards the core 
development and recipes like this that are targeted for the main "meta" 
layer.


You should resend this patch to: openembedded-core@lists.openembedded.org.

regards,

Armin


On 05/09/2017 02:10 PM, Marek Belisko wrote:

libgpiod - C library and tools for interacting with the linux GPIO
character device

Since linux 4.8 the GPIO sysfs interface is deprecated.
User space should use the character device instead.
This library encapsulates the ioctl calls and data structures behind a
straightforward API.

Signed-off-by: Marek Belisko 
---
  meta/recipes-support/libgpiod/libgpiod_0.2.bb | 25 +
  1 file changed, 25 insertions(+)
  create mode 100644 meta/recipes-support/libgpiod/libgpiod_0.2.bb

diff --git a/meta/recipes-support/libgpiod/libgpiod_0.2.bb 
b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
new file mode 100644
index 000..fe2cd80
--- /dev/null
+++ b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
@@ -0,0 +1,25 @@
+SUMMARY = "C library and tools for interacting with the linux GPIO character 
device"
+HOMEPAGE = "https://github.com/brgl/libgpiod";
+
+LICENSE = "LGPLv2.1+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=2caced0b25dfefd4c601d92bd15116de"
+
+UPSTREAM_CHECK_URI = "https://github.com/brgl/libgpiod/releases";
+
+SRC_URI = "https://github.com/brgl/libgpiod/archive/v${PV}.tar.gz";
+
+SRC_URI[md5sum] = "e3430f35b6efa842693d659c0bfb7ad5"
+SRC_URI[sha256sum] = 
"de1947f3cb2cc4174364af430309fe6238976658575655bdbd76c60cffa7df92"
+
+inherit autotools pkgconfig
+
+# enable tools
+PACKAGECONFIG ?= "tools"
+
+PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,kmod udev"
+PACKAGECONFIG[tools] = "--enable-tools,--disable-tools,"
+
+PACKAGES += " ${PN}-tools"
+
+FILES_${PN} = "${libdir}/*"
+FILES_${PN}-tools = "${bindir}/*"


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

Re: [OE-core] GUI based images

[Paul Eggleton]

On Wednesday, 10 May 2017 8:39:58 AM NZST Alexander Kanavin wrote:
> On 05/09/2017 11:19 PM, Khem Raj wrote:
> > I think we should always intend to align the reference stack with
> > whats commonly used in
> > userbases we target to address with project, we will not be serving
> > the project goals and its username if we
> > trim down to packages which are just used for reference, if majority of
> > the community we intend to address uses QT or any other stack for that
> > matter then we should align our requirements accordingly which will be
> > mutually beneficial IMO
> 
> I strongly disagree. Oe-core is not a Greatest Embedded Hits collection 
> or any kind of 'reference stack', and decisions on what goes into it 
> should not be based on how popular it is. 

A number of things have been added to OE-Core because they are widely used, so 
I don't think that's true. However, that doesn't mean that would be used as a 
justification to add Qt5. I'm not even convinced we would need to add Qt5 to 
OE-Core in order to use it as part of a reference UI - the key requirement 
would be for us to commit to being part of its testing and maintenance, 
everything else is just logistics.

> If you do this, you risk overextending the layer, and ending up not doing a
> particularly good job on any of the things it tries to do. It's best to
> allow other layers to  flourish, let the domain specialists do their job and
> decide for themselves how they want to do things, and have a curated list of
> layers that are known to be high quality and approved by Yocto Project.
> 
> If you want qt5, use meta-qt5 and meta-b2qt, both made by people who 
> actually develop the Qt stack itself. End of story.

Your opinion is noted. My opinion is that we ought to be providing a good 
reference that can be used as a basis for real products (regardless of whether 
whatever direction we choose to go is Qt-based or not) - the rest of our stack 
*is* used that way, after all. We regularly get comments about how Sato isn't 
suitable as such a basis, so the expectation is there. I don't think adding 
Wayland support alone will answer that.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] GUI based images

[Khem Raj]

On Tue, May 9, 2017 at 1:39 PM, Alexander Kanavin
 wrote:
> On 05/09/2017 11:19 PM, Khem Raj wrote:
>>
>> I think we should always intend to align the reference stack with
>> whats commonly used in
>> userbases we target to address with project, we will not be serving
>> the project goals and its username if we
>> trim down to packages which are just used for reference, if majority of
>> the
>> community we intend to address uses QT or any other stack for that matter
>> then we should align our requirements accordingly which will be mutually
>> beneficial IMO
>
>
> I strongly disagree. Oe-core is not a Greatest Embedded Hits collection or
> any kind of 'reference stack', and decisions on what goes into it should not
> be based on how popular it is. If you do this, you risk overextending the
> layer, and ending up not doing a particularly good job on any of the things
> it tries to do. It's best to allow other layers to flourish, let the domain
> specialists do their job and decide for themselves how they want to do
> things, and have a curated list of layers that are known to be high quality
> and approved by Yocto Project.
>
> If you want qt5, use meta-qt5 and meta-b2qt, both made by people who
> actually develop the Qt stack itself. End of story.

Don't get bogged down with QT5, its not at all about QT5 or no qt5,see
it from a users point of view and you will probably understand what I
am trying to say. Relevance of what you include in core is very
essential. Look at
any infra typical example is android, they ensure what consists of the core
pieces and keep them aligned and add/remove major pieces with newer
releases. We need to always evaluate coverage of core and make amends
if we dont then integration efforts become more over releases and at
some point a distro can decide its not worth using OE-Core and fork.
So evaluating
the sub-systems should always be done and we should not be afraid of
shuffling the cards if that aligns well with what the users are needing at
a certain point in time.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [meta-oe][resend][PATCH] sysstat: fixup pkg_postinst to allow SYSTEMD_AUTO_ENABLE to work

[Mark Asselstine]

The logic added to the pkg_postinst in commit 6bf82c26f953 has the
side effect of rendering SYSTEMD_AUTO_ENABLE ineffective. The systemd
service will not be configured as 'enabled' either offline(do_rootfs)
or during first boot. Since the volatiles, as used, in the
pkg_postinst are unused with systemd we can simply skip the
pkg_postinst when not using sysvinit.

Signed-off-by: Mark Asselstine 
---
 meta/recipes-extended/sysstat/sysstat.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/sysstat/sysstat.inc 
b/meta/recipes-extended/sysstat/sysstat.inc
index bb5629d..fce2804 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -42,7 +42,9 @@ do_install() {
sed -i -e 's#@LIBDIR@#${libdir}#g' 
${D}${systemd_unitdir}/system/sysstat.service
 }
 
-pkg_postinst_${PN} () {
+OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 
':sysvinit', '', d)}"
+
+pkg_postinst_${PN}_sysvinit () {
 if [ -n "$D" ]; then
 exit 0
 fi
-- 
2.7.4

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

Re: [OE-core] GUI based images

[Alexander Kanavin]

On 05/09/2017 11:19 PM, Khem Raj wrote:

I think we should always intend to align the reference stack with
whats commonly used in
userbases we target to address with project, we will not be serving
the project goals and its username if we
trim down to packages which are just used for reference, if majority of the
community we intend to address uses QT or any other stack for that matter
then we should align our requirements accordingly which will be mutually
beneficial IMO


I strongly disagree. Oe-core is not a Greatest Embedded Hits collection 
or any kind of 'reference stack', and decisions on what goes into it 
should not be based on how popular it is. If you do this, you risk 
overextending the layer, and ending up not doing a particularly good job 
on any of the things it tries to do. It's best to allow other layers to 
flourish, let the domain specialists do their job and decide for 
themselves how they want to do things, and have a curated list of layers 
that are known to be high quality and approved by Yocto Project.


If you want qt5, use meta-qt5 and meta-b2qt, both made by people who 
actually develop the Qt stack itself. End of story.


Alex

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

Re: [OE-core] GUI based images

[Khem Raj]

On Tue, May 9, 2017 at 2:24 AM, Burton, Ross  wrote:
>
> On 8 May 2017 at 23:15, Paul Eggleton  wrote:
>>
>> FWIW I think this is a little short-sighted. Why are we ruling out Qt
>> exactly?
>
>
> My only strong opinion on what goes into oe-core is that it should be small
> (both in size and build time) and basic.  It's not going to fit everyones
> needs and is basically there to be a UI until the users replace it with
> something more suitable.  Sato does this without being too huge and there's
> not currently a strong impetus to replace it.
>
> The development of Wayland does make the long-term prospect of Sato
> interesting: do we port Sato to Wayland too, or keep the Wayland images
> using the standard Weston demo shell?

I think we should always intend to align the reference stack with
whats commonly used in
userbases we target to address with project, we will not be serving
the project goals and its username if we
trim down to packages which are just used for reference, if majority of the
community we intend to address uses QT or any other stack for that matter
then we should align our requirements accordingly which will be mutually
beneficial IMO
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] GUI based images

[Max Krummenacher]

Am Dienstag, den 09.05.2017, 11:10 +0300 schrieb Alexander Kanavin:
> On 05/09/2017 01:50 AM, Khem Raj wrote:
> > A general usecase is that someone takes the reference and tweaks it to
> > meet the needs of a product quickly. For such usecases, it would be good to
> > consider the most widely used UI framework in embedded space. I
> > personally don't know how much sato is deployed but QT based systems
> > are quite widely deployed as far as I know. I think users can drive maximum
> > out of the testing and stabilization we do if they were using the reference
> > software as much as possible.
> 
> Qt itself does not provide a UI, so we would need to find an appropriate 
> qt-based replacement for Sato that has the same characteristics and is 
> suitable as an 'engineering UI'. What is your suggestion for that?
> 
> I personally think meta-qt5 works fine; it's only missing a reference UI 
> environment. Why not add LxQt to that layer?
> 
Andreas already has those recipes in meta-qt5-extra:
https://layers.openembedded.org/layerindex/recipe/39614/

And for those who want a look at LXDE:
http://git.toradex.com/cgit/meta-lxde.git/tree/recipes-lxde/packagegroup/packagegroup-lxde-extended.
bb?h=master

Max

> 
> Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] python3-nose: rename ${bindir}/nosetests into ${bindir}/nosetests3

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

This resolves a conflict when both python-nose and python3-nose are pulled
into an image and try to install ${bindir}/nosetests binary.

This matches with how other distros are solving this problem, e.g. Debian:
https://packages.debian.org/jessie/all/python3-nose/filelist

Also, other packages like python3-setuptools are already doing the same with
their binaries.

Signed-off-by: Denys Dmytriyenko 
---
 meta/recipes-devtools/python/python3-nose_1.3.7.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-nose_1.3.7.bb 
b/meta/recipes-devtools/python/python3-nose_1.3.7.bb
index 99bba44..1e2ff74 100644
--- a/meta/recipes-devtools/python/python3-nose_1.3.7.bb
+++ b/meta/recipes-devtools/python/python3-nose_1.3.7.bb
@@ -17,6 +17,10 @@ S = "${WORKDIR}/nose-${PV}"
 
 inherit setuptools3
 
+do_install_append() {
+mv ${D}${bindir}/nosetests ${D}${bindir}/nosetests3
+}
+
 RDEPENDS_${PN}_class-target = "\
   python3-unittest \
   "
-- 
2.7.4

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

Re: [OE-core] [PATCH 2/3] DEBIAN_MIRROR: switch from ftp to http

[Alexander Kanavin]

On 05/09/2017 07:19 PM, Maxin B. John wrote:

All public-facing debian.org FTP services will be shut down on November 1, 2017
The mirrors should just be accessed using HTTP instead.


Let's discourage the use of ftp in recipes in general; it's a 1970s relic.


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

Re: [OE-core] [PATCH] libnl: 3.2.29 -> 3.3.0

[Khem Raj]

On Tue, May 9, 2017 at 6:18 AM, Burton, Ross  wrote:
>
> On 8 May 2017 at 10:39, Huang Qiyu  wrote:
>>
>> 1) Upgrade libnl from 3.2.29 to 3.3.0.
>> 2) Delete patch "fix-pktloc_syntax_h-race.patch", since it is integrated
>> upstream.
>
>
> Breaks under musl:
>
> In file included from ../libnl-3.3.0/include/linux-private/linux/ipv6.h:5:0,
>  from ../libnl-3.3.0/include/netlink-private/netlink.h:54,
>  from ../libnl-3.3.0/lib/nl.c:28:
> ../libnl-3.3.0/include/linux-private/linux/in6.h:32:8: error: redefinition
> of 'struct in6_addr'
>  struct in6_addr {
> ^~~~
>
> In file included from
> TOPDIR/tmp/work/i586-poky-linux-musl/libnl/1_3.3.0-r0/recipe-sysroot/usr/include/arpa/inet.h:9:0,
>  from ../libnl-3.3.0/include/netlink-private/netlink.h:32,
>  from ../libnl-3.3.0/lib/nl.c:28:
> TOPDIR/tmp/work/i586-poky-linux-musl/libnl/1_3.3.0-r0/recipe-sysroot/usr/include/netinet/in.h:23:8:
> note: originally defined here
>  struct in6_addr {
> ^~~~
>

you can cook a fix based on
https://lists.01.org/pipermail/connman/2016-August/020853.html

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

[OE-core] [PATCH 1/3] useradd: remove preinst script referring to recipe sysroot

[Maxin B. John]

Remove recipe-specific-sysroot details from the preinst scripts
generated by useradd.bbclass.

Fixes [YOCTO #11460]

Signed-off-by: Maxin B. John 
---
 meta/classes/useradd.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
index 4373677..06121b7 100644
--- a/meta/classes/useradd.bbclass
+++ b/meta/classes/useradd.bbclass
@@ -32,7 +32,7 @@ if test "x$D" != "x"; then
fi
 
# user/group lookups should match useradd/groupadd --root
-   export PSEUDO_PASSWD="$SYSROOT:${STAGING_DIR_NATIVE}"
+   export PSEUDO_PASSWD="$SYSROOT"
 fi
 
 # If we're not doing a special SSTATE/SYSROOT install
-- 
2.4.0

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

[OE-core] [PATCH 2/3] DEBIAN_MIRROR: switch from ftp to http

[Maxin B. John]

All public-facing debian.org FTP services will be shut down on November 1, 2017
The mirrors should just be accessed using HTTP instead.

https://www.debian.org/News/2017/20170425

Fixes [YOCTO #11413]

Signed-off-by: Maxin B. John 
---
 meta/classes/mirrors.bbclass | 34 +-
 meta/conf/bitbake.conf   |  4 ++--
 2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass
index 1174ef6..9c83463 100644
--- a/meta/classes/mirrors.bbclass
+++ b/meta/classes/mirrors.bbclass
@@ -2,23 +2,23 @@ MIRRORS += "\
 ${DEBIAN_MIRROR}   
http://snapshot.debian.org/archive/debian-archive/20120328T092752Z/debian/pool 
\n \
 ${DEBIAN_MIRROR}   
http://snapshot.debian.org/archive/debian-archive/20110127T084257Z/debian/pool 
\n \
 ${DEBIAN_MIRROR}   
http://snapshot.debian.org/archive/debian-archive/20090802T004153Z/debian/pool 
\n \
-${DEBIAN_MIRROR}   ftp://ftp.de.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.au.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.cl.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.hr.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.fi.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.hk.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.hu.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.ie.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.it.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.jp.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.no.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.pl.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.ro.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.si.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.es.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.se.debian.org/debian/pool \n \
-${DEBIAN_MIRROR}   ftp://ftp.tr.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.de.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.au.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.cl.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.hr.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.fi.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.hk.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.hu.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.ie.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.it.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.jp.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.no.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.pl.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.ro.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.si.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.es.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.se.debian.org/debian/pool \n \
+${DEBIAN_MIRROR}   http://ftp.tr.debian.org/debian/pool \n \
 ${GNU_MIRROR}  ftp://mirrors.kernel.org/gnu \n \
 ${KERNELORG_MIRROR}http://www.kernel.org/pub \n \
 ${GNUPG_MIRROR}ftp://ftp.gnupg.org/gcrypt \n \
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index a24be05..83158fd 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -600,7 +600,7 @@ BBLAYERS_FETCH_DIR ??= "${COREBASE}"
 ##
 
 APACHE_MIRROR = "http://archive.apache.org/dist";
-DEBIAN_MIRROR = "ftp://ftp.debian.org/debian/pool";
+DEBIAN_MIRROR = "http://ftp.debian.org/debian/pool";
 GENTOO_MIRROR = "http://distfiles.gentoo.org/distfiles";
 GNOME_GIT = "git://git.gnome.org"
 GNOME_MIRROR = "http://ftp.gnome.org/pub/GNOME/sources";
@@ -634,7 +634,7 @@ SRC_URI[vardepsexclude] += "\
 "
 
 # You can use the mirror of your country to get faster downloads by putting
-#  export DEBIAN_MIRROR = "ftp://ftp.de.debian.org/debian/pool";
+#  export DEBIAN_MIRROR = "http://ftp.de.debian.org/debian/pool";
 # into your local.conf
 
 FETCHCMD_svn = "/usr/bin/env svn --non-interactive --trust-server-cert"
-- 
2.4.0

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

[OE-core] [PATCH 3/3] GNU_MIRROR: switch from ftp to https

[Maxin B. John]

Based on the same reason behind DEBIAN's switch from ftp:
https://www.debian.org/News/2017/20170425

Signed-off-by: Maxin B. John 
---
 meta/classes/mirrors.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass
index 9c83463..b7c20b6 100644
--- a/meta/classes/mirrors.bbclass
+++ b/meta/classes/mirrors.bbclass
@@ -19,7 +19,7 @@ ${DEBIAN_MIRROR}  http://ftp.si.debian.org/debian/pool \n 
\
 ${DEBIAN_MIRROR}   http://ftp.es.debian.org/debian/pool \n \
 ${DEBIAN_MIRROR}   http://ftp.se.debian.org/debian/pool \n \
 ${DEBIAN_MIRROR}   http://ftp.tr.debian.org/debian/pool \n \
-${GNU_MIRROR}  ftp://mirrors.kernel.org/gnu \n \
+${GNU_MIRROR}  https://mirrors.kernel.org/gnu \n \
 ${KERNELORG_MIRROR}http://www.kernel.org/pub \n \
 ${GNUPG_MIRROR}ftp://ftp.gnupg.org/gcrypt \n \
 ${GNUPG_MIRROR}
ftp://ftp.franken.de/pub/crypt/mirror/ftp.gnupg.org/gcrypt \n \
-- 
2.4.0

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

[OE-core] ✗ patchtest: failure for kconfig-frontends: fix build race

[Patchwork]

== Series Details ==

Series: kconfig-frontends: fix build race
Revision: 1
URL   : https://patchwork.openembedded.org/series/6651/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 1239620182)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH] kconfig-frontends: fix build race

[Ross Burton]

In parallel builds utils/kconfig-tweak may be written to before utils/ exists,
so add a mkdir.

Also mark the pkgconfig patch as Submitted as I sent that upstream at the same
time.

Signed-off-by: Ross Burton 
---
 .../files/0001-Fix-installation-of-.pc-files.patch |  3 +-
 .../kconfig-frontends/files/missing-mkdir.patch| 33 ++
 .../kconfig-frontends_4.10.0.1.bb  |  3 +-
 3 files changed, 36 insertions(+), 3 deletions(-)
 create mode 100644 
meta/recipes-devtools/kconfig-frontends/files/missing-mkdir.patch

diff --git 
a/meta/recipes-devtools/kconfig-frontends/files/0001-Fix-installation-of-.pc-files.patch
 
b/meta/recipes-devtools/kconfig-frontends/files/0001-Fix-installation-of-.pc-files.patch
index e9195a0..57ea42e 100644
--- 
a/meta/recipes-devtools/kconfig-frontends/files/0001-Fix-installation-of-.pc-files.patch
+++ 
b/meta/recipes-devtools/kconfig-frontends/files/0001-Fix-installation-of-.pc-files.patch
@@ -5,7 +5,7 @@ Subject: [PATCH] Fix installation of .pc files
 
 They go to prefix/pkgconfig/, not prefix/pkg-config.
 
-Upstream-Status: Pending
+Upstream-Status: Submitted
 Signed-off-by: Alexander Kanavin 
 ---
  Makefile.am | 2 +-
@@ -26,4 +26,3 @@ index 058690a..f9e9b7b 100644
  EXTRA_DIST += libs/parser/kconfig-parser.pc.in
 -- 
 2.11.0
-
diff --git a/meta/recipes-devtools/kconfig-frontends/files/missing-mkdir.patch 
b/meta/recipes-devtools/kconfig-frontends/files/missing-mkdir.patch
new file mode 100644
index 000..a06a547
--- /dev/null
+++ b/meta/recipes-devtools/kconfig-frontends/files/missing-mkdir.patch
@@ -0,0 +1,33 @@
+Upstream-Status: Submitted
+Signed-off-by: Ross Burton 
+
+From ca05ee2fb6db5b3b1edc16dba6150a2c6078a6cf Mon Sep 17 00:00:00 2001
+From: Ross Burton 
+Date: Tue, 9 May 2017 15:30:00 +0100
+Subject: [PATCH] Makefile: ensure utils/ exists before writing to it
+
+Since utils/ was changed to not build recursively it's possible that in
+out-of-tree builds the utils/ directory hasn't been created when Make runs the
+utils/kconfig-tweak target which tries to write to file inside utils/.
+
+To ensure this can work, mkdir the directory.
+
+Signed-off-by: Ross Burton 
+---
+ Makefile.am | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/Makefile.am b/Makefile.am
+index c8e96ef..1baa110 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -348,6 +348,7 @@ EXTRA_DIST += \
+   utils/kconfig-tweak.in.patch
+ 
+ utils/kconfig-tweak: utils/kconfig-tweak.in
++  $(MKDIR_P) $(@D)
+   $(AM_V_GEN)$(SED) -e "s/@CONFIG_@/$(config_prefix)/g" \
+   $< >$@
+   @chmod +x $@
+-- 
+2.8.1
diff --git 
a/meta/recipes-devtools/kconfig-frontends/kconfig-frontends_4.10.0.1.bb 
b/meta/recipes-devtools/kconfig-frontends/kconfig-frontends_4.10.0.1.bb
index be90d6b..d427e98 100644
--- a/meta/recipes-devtools/kconfig-frontends/kconfig-frontends_4.10.0.1.bb
+++ b/meta/recipes-devtools/kconfig-frontends/kconfig-frontends_4.10.0.1.bb
@@ -15,7 +15,8 @@ DEPENDS += "ncurses flex bison gperf-native"
 RDEPENDS_${PN} += "python3 bash"
 SRC_URI = "git://ymorin.is-a-geek.org/kconfig-frontends;branch=4.10.x \
file://0001-Fix-installation-of-.pc-files.patch \
-   file://0001-Switch-utils-kconfig-diff-to-use-Python-3.patch"
+   file://0001-Switch-utils-kconfig-diff-to-use-Python-3.patch \
+   file://missing-mkdir.patch"
 
 SRCREV = "f8ffe5e1c6f183cb7d5d515aa9381b7557de654e"
 
-- 
2.8.1

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

Re: [OE-core] [PATCH] libnl: 3.2.29 -> 3.3.0

[Burton, Ross]

On 8 May 2017 at 10:39, Huang Qiyu  wrote:
>
> 1) Upgrade libnl from 3.2.29 to 3.3.0.
> 2) Delete patch "fix-pktloc_syntax_h-race.patch", since it is integrated
upstream.


Breaks under musl:

In file included from ../libnl-3.3.0/include/linux-private/linux/ipv6.h:5:0,
 from ../libnl-3.3.0/include/netlink-private/netlink.h:54,
 from ../libnl-3.3.0/lib/nl.c:28:
../libnl-3.3.0/include/linux-private/linux/in6.h:32:8: error: redefinition
of 'struct in6_addr'
 struct in6_addr {
^~~~

In file included from
TOPDIR/tmp/work/i586-poky-linux-musl/libnl/1_3.3.0-r0/recipe-sysroot/usr/include/arpa/inet.h:9:0,
 from ../libnl-3.3.0/include/netlink-private/netlink.h:32,
 from ../libnl-3.3.0/lib/nl.c:28:
TOPDIR/tmp/work/i586-poky-linux-musl/libnl/1_3.3.0-r0/recipe-sysroot/usr/include/netinet/in.h:23:8:
note: originally defined here
 struct in6_addr {
^~~~

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

[OE-core] [PATCH] gcr: add missing dependency on xsltproc if introspection is enabled

[Ross Burton]

gcr needs xsltproc at build time if GObject Introspection is enabled.

Also, remove the explicit disabling of g-i and gtk-doc on x86-64 targets, this
appears to work now.

Signed-off-by: Ross Burton 
---
 meta/recipes-gnome/gcr/gcr_3.20.0.bb | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/meta/recipes-gnome/gcr/gcr_3.20.0.bb 
b/meta/recipes-gnome/gcr/gcr_3.20.0.bb
index f31abce..4450e15 100644
--- a/meta/recipes-gnome/gcr/gcr_3.20.0.bb
+++ b/meta/recipes-gnome/gcr/gcr_3.20.0.bb
@@ -5,7 +5,8 @@ BUGTRACKER = "https://bugzilla.gnome.org/";
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605"
 
-DEPENDS = "intltool-native gtk+3 p11-kit glib-2.0 libgcrypt"
+DEPENDS = "intltool-native gtk+3 p11-kit glib-2.0 libgcrypt \
+   ${@bb.utils.contains('GI_DATA_ENABLED', 'True', 'libxslt-native', 
'', d)}"
 
 inherit autotools gnomebase gtk-icon-cache gtk-doc distro_features_check 
upstream-version-is-even vala gobject-introspection
 # depends on gtk+3, but also x11 through gtk+-x11
@@ -23,16 +24,3 @@ FILES_${PN} += " \
 
 # http://errors.yoctoproject.org/Errors/Details/20229/
 ARM_INSTRUCTION_SET = "arm"
-
-# on x86-64 the introspection binary goes into 
-# an infinite loop under qemu during compilation, 
-# printing the following:
-# 
-# gcrypt-Message: select() error: Bad address
-#
-# gcrypt-Message: select() error: Bad address
-#
-# gcrypt-Message: select() error: Bad address
-#
-# This will be investigated later.
-EXTRA_OECONF_append_x86-64 = " --disable-introspection --disable-gtk-doc"
-- 
2.8.1

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

Re: [OE-core] PulseAudio with WebRTC echo cancellation (aec): support for webrtc-audio-processing package

[Koenraad Verheyden]

Hi Tanu,

I've written a script myself, referencing how other scripts did this. Was
indeed not so hard.
This is the first time writing such a script so I can't guarantee
everything is correct or the right way to do (especially the license
stuff). But this works for me.

You can do with this script as you want.

With kind regards,
Koenraad

The script:
==
DESCRIPTION = "This is meant to be a more Linux packaging friendly copy of
the AudioProcessing module from the WebRTC project."
HOMEPAGE = "
https://www.freedesktop.org/software/pulseaudio/webrtc-audio-processing/";
LICENSE = "BSD-3-Clause"
LIC_FILES_CHKSUM = "file://COPYING;md5=da08a38a32a340c5d91e13ee86a118f2"

SRC_URI = "http://freedesktop.org/software/pulseaudio/${BPN}/${BP}.tar.xz";
SRC_URI[md5sum] = "336ae032f608e65808ac577cde0ab72c"
SRC_URI[sha256sum] =
"756e291d4f557d88cd50c4fe3b8454ec238362d22cedb3e6173240d90f0a80fa"

inherit autotools
==

On 21 April 2017 at 11:53, Tanu Kaskinen  wrote:

> On Thu, 2017-04-20 at 22:14 +0200, Koenraad Verheyden wrote:
> > I am not familiar with the organization of the various recipes. I
> > mentioned oe-core since the original message was posted there.
> > Meta-oe seems more suitable indeed.
> >
> > How much work would it be to make a recipe for this?
> > I need it for a short-term project and am not in a position to further
> > support it afterwards.
>
> Writing the recipe should be fairly simple. I can do that at some
> point, but if you want it fast, write the recipe yourself. I volunteer
> to maintain it.
>
> --
> Tanu
>
> https://www.patreon.com/tanuk
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] GUI based images

[Mike Looijmans]

On 09-05-17 10:44, Alex J Lennon wrote:



On 09/05/17 09:05, Alexander Kanavin wrote:

On 05/09/2017 01:15 AM, Paul Eggleton wrote:

LXDE in particular is Gtk2 based, it's no longer being developed, and
has been superseded by LXQt. So it's a non-starter (and so is LXQt,
which should be clear from its name :).


FWIW I think this is a little short-sighted. Why are we ruling out Qt exactly?


We would first have to agree that Qt5 belongs in oe-core with appropriate
level of maintenance and QA, and that it's okay to add half an hour or more
to the building time of a standard GUI image.

From the screenshots of LxQT, it looks like yet another Win95 clone meant
strictly for desktop use that would certainly scale poorly to small
resolution screens. Who would be the target audience for it in the embedded
space? For the purposes of 'engineering UI', Sato is fine, and we don't need
something else.

Alex


fwiw. I would love to be able to develop devices like those pictured below,
which I believe are based on Qt for Device Creation.

https://d33sqmjvzgs8hq.cloudfront.net/wp-content/uploads/2014/08/devices.png


Things like that can be cooked up in OE using just meta-qt4 (or 5, but haven't 
tried yet) and a main application recipe (just a QT project that you develop 
on your desktop) that inherits qt4e.


Qt doesn't need X11, saving big on build and boot time.

A Zynq demo running QT on a plain framebuffer boots in about 7 seconds (from 
NOR flash) into the fully functional GUI, on a 10" touch panel, and all of it 
fits in about 20MB flash storage.




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [OE-core] GUI based images

[Burton, Ross]

On 9 May 2017 at 10:30, Alexander Kanavin  wrote:

> Seriously, for those who say that qt5 should be in oe.core - this does the
> job far better than oe-core ever would.
>

This. :)

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

Re: [OE-core] GUI based images

[Alexander Kanavin]

On 05/09/2017 12:18 PM, Ian Arkver wrote:

They have their own meta-b2qt layer for that. See "Embedded
documentation" and "Building Your Own Embedded Linux Image" from that
page.

It's not an OE-core thing, imho.


I digged a bit deeper, and meta-b2qt is in fact open source:

http://code.qt.io/cgit/yocto/meta-boot2qt.git/tree/README

"Boot to Qt (b2qt) is the reference distro used in Qt for Device 
Creation [1]. It combines Poky, meta-qt5 and various BSP meta layers to 
provide an integrated solution for building device images and toolchains 
with the latest Qt version."


Seriously, for those who say that qt5 should be in oe.core - this does 
the job far better than oe-core ever would.


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

[OE-core] [PATCH V2 0/1] cve-check.bbclass: make warning contain CVE IDs

[Chen Qi]

The following changes since commit 381897c64069ea43d595380a3ae913bcc79cf7e1:

  build-appliance-image: Update to master head revision (2017-05-01 08:56:47 
+0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/cve-check-warning
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/cve-check-warning

Chen Qi (1):
  cve-check.bbclass: make warning contain CVE IDs

 meta/classes/cve-check.bbclass | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

-- 
1.9.1

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

[OE-core] [PATCH V2 1/1] cve-check.bbclass: make warning contain CVE IDs

[Chen Qi]

When warning users about unpatched CVE, we'd better put CVE IDs into
the warning message, so that it would be more straight forward for the
user to know which CVEs are not patched.

So instead of:
  WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE, for more 
information check /path/to/workdir/cve/cve.log.
We should have:
  WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE (CVE-2017-7869), 
for more information check /path/to/workdir/cve/cve.log.

Signed-off-by: Chen Qi 
---
 meta/classes/cve-check.bbclass | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 0e4294f..3a9e227 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -234,7 +234,7 @@ def cve_write_data(d, patched, unpatched, cve_data):
 cve_file = d.getVar("CVE_CHECK_LOCAL_FILE")
 nvd_link = "https://web.nvd.nist.gov/view/vuln/detail?vulnId=";
 write_string = ""
-first_alert = True
+unpatched_cves = []
 bb.utils.mkdirhier(d.getVar("CVE_CHECK_LOCAL_DIR"))
 
 for cve in sorted(cve_data):
@@ -244,15 +244,16 @@ def cve_write_data(d, patched, unpatched, cve_data):
 if cve in patched:
 write_string += "CVE STATUS: Patched\n"
 else:
+unpatched_cves.append(cve)
 write_string += "CVE STATUS: Unpatched\n"
-if first_alert:
-bb.warn("Found unpatched CVE, for more information check %s" % 
cve_file)
-first_alert = False
 write_string += "CVE SUMMARY: %s\n" % cve_data[cve]["summary"]
 write_string += "CVSS v2 BASE SCORE: %s\n" % cve_data[cve]["score"]
 write_string += "VECTOR: %s\n" % cve_data[cve]["vector"]
 write_string += "MORE INFORMATION: %s%s\n\n" % (nvd_link, cve)
 
+if unpatched_cves:
+bb.warn("Found unpatched CVE (%s), for more information check %s" % (" 
".join(unpatched_cves),cve_file))
+
 with open(cve_file, "w") as f:
 bb.note("Writing file %s with CVE information" % cve_file)
 f.write(write_string)
-- 
1.9.1

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

Re: [OE-core] GUI based images

[Burton, Ross]

On 8 May 2017 at 23:15, Paul Eggleton  wrote:

> FWIW I think this is a little short-sighted. Why are we ruling out Qt
> exactly?
>

My only strong opinion on what goes into oe-core is that it should be small
(both in size and build time) and basic.  It's not going to fit everyones
needs and is basically there to be a UI until the users replace it with
something more suitable.  Sato does this without being too huge and there's
not currently a strong impetus to replace it.

The development of Wayland does make the long-term prospect of Sato
interesting: do we port Sato to Wayland too, or keep the Wayland images
using the standard Weston demo shell?

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

Re: [OE-core] [PATCH 1/1] cve-check.bbclass: make warning contain CVE IDs

[ChenQi]

On 05/09/2017 05:17 PM, Joshua Lock wrote:

On Tue, 2017-05-09 at 17:13 +0800, Chen Qi wrote:

When warning users about unpatched CVE, we'd better put CVE IDs into
the warning message, so that it would be more straight forward for
the
user to know which CVEs are not patched.

So instead of:
   WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE, for
more information check /path/to/workdir/cve/cve.log.
We should have:
   WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE (CVE-
2017-7869), for more information check /path/to/workdir/cve/cve.log.

Signed-off-by: Chen Qi 
---
  meta/classes/cve-check.bbclass | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-
check.bbclass
index 0e4294f..496d744 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -234,7 +234,8 @@ def cve_write_data(d, patched, unpatched,
cve_data):
  cve_file = d.getVar("CVE_CHECK_LOCAL_FILE")
  nvd_link = "https://web.nvd.nist.gov/view/vuln/detail?vulnId=";
  write_string = ""
-first_alert = True
+has_unpatched_cve = False
+unpatched_cves = []
  bb.utils.mkdirhier(d.getVar("CVE_CHECK_LOCAL_DIR"))
  
  for cve in sorted(cve_data):

@@ -244,15 +245,17 @@ def cve_write_data(d, patched, unpatched,
cve_data):
  if cve in patched:
  write_string += "CVE STATUS: Patched\n"
  else:
+unpatched_cves.append(cve)
  write_string += "CVE STATUS: Unpatched\n"
-if first_alert:
-bb.warn("Found unpatched CVE, for more information
check %s" % cve_file)
-first_alert = False
+has_unpatched_cve = True
  write_string += "CVE SUMMARY: %s\n" %
cve_data[cve]["summary"]
  write_string += "CVSS v2 BASE SCORE: %s\n" %
cve_data[cve]["score"]
  write_string += "VECTOR: %s\n" % cve_data[cve]["vector"]
  write_string += "MORE INFORMATION: %s%s\n\n" % (nvd_link,
cve)
  
+if has_unpatched_cve:

There's no need for the has_unpatched_cve variable, you can just test
whether the unpatched_cves list is empty:


foo = []
bar = [1, 2, 3]
if foo:

...   print("foo")
...

if bar:

...   print("bar")
...
bar

Your conditional can just be:

   + if unpatched_cve:


Thanks a lot.
I'll send out V2.

Best Regards,
Chen Qi


+bb.warn("Found unpatched CVE (%s), for more information
check %s" % (" ".join(unpatched_cves),cve_file))
+
  with open(cve_file, "w") as f:
  bb.note("Writing file %s with CVE information" % cve_file)
  f.write(write_string)
--
1.9.1



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

Re: [OE-core] [PATCH 2/2] connman: enable connman-wait-online.service

[Andreas Oberritter]

Ping, again, for this very simple patch.

On Mon, 30 Jan 2017 23:20:02 +0100
Andreas Oberritter  wrote:

> Ping.
> 
> On Wed, 30 Nov 2016 13:22:31 +0100
> Andreas Oberritter  wrote:
> 
> > Fixes network mounts on boot.
> > 
> > Signed-off-by: Andreas Oberritter 
> > ---
> >  meta/recipes-connectivity/connman/connman.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-connectivity/connman/connman.inc 
> > b/meta/recipes-connectivity/connman/connman.inc
> > index 091e402..0480257 100644
> > --- a/meta/recipes-connectivity/connman/connman.inc
> > +++ b/meta/recipes-connectivity/connman/connman.inc
> > @@ -56,7 +56,7 @@ PACKAGECONFIG[wispr] = 
> > "--enable-wispr,--disable-wispr,gnutls,"
> >  INITSCRIPT_NAME = "connman"
> >  INITSCRIPT_PARAMS = "start 05 5 2 3 . stop 22 0 1 6 ."
> >  
> > -SYSTEMD_PACKAGES = "${PN} ${PN}-vpn"
> > +SYSTEMD_PACKAGES = "${PN} ${PN}-vpn ${PN}-wait-online"
> >  SYSTEMD_SERVICE_${PN} = "connman.service"
> >  SYSTEMD_SERVICE_${PN}-vpn = "connman-vpn.service"
> >  SYSTEMD_SERVICE_${PN}-wait-online = "connman-wait-online.service"  
> 

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

Re: [OE-core] GUI based images

[Alexander Kanavin]

On 05/09/2017 11:44 AM, Alex J Lennon wrote:

fwiw. I would love to be able to develop devices like those pictured
below, which I believe are based on Qt for Device Creation.

https://d33sqmjvzgs8hq.cloudfront.net/wp-content/uploads/2014/08/devices.png


ref: https://www.qt.io/qt-for-device-creation/


Sadly, Qt for Device Creation is a commercial product. They even provide 
Yocto recipes :)


Alex

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

Re: [OE-core] [PATCH] connman: Simplify and fix packaging of VPN plug-ins

[Andreas Oberritter]

Ping.

I know conflicts may have appeared in the meantime. I've got a rebased
version in my tree. Some feedback would be nice however, before I'm going
to send it again.

Regards,
Andreas

On Mon, 30 Jan 2017 23:19:30 +0100
Andreas Oberritter  wrote:

> Ping.
> 
> On Mon,  5 Dec 2016 23:41:53 +0100
> Andreas Oberritter  wrote:
> 
> > - Use simple static packaging.
> > - Move VPN runtime dependencies from connman to the individual plug-ins.
> > - Create a connmann-ppp package containing libppp-plugin.so, which is
> >   a shared library needed by l2tp and pptp plug-ins.
> > - Let connman suggest VPN packages instead of recommending them, so they
> >   don't get installed by default.
> > - Remove unknown configure options (--with-pptp --with-l2tp)
> > 
> > Signed-off-by: Andreas Oberritter 
> > ---
> >  v2: Made dependencies from meta-networking conditional. Now the reported
> >  errors should appear only if meta-network is not available and a
> >  packageconfig option related to VPN was enabled.
> > 
> >  Note: I can't build-test it right now, because python3-native has weird
> >conflicts populating sysroot. But this patch doesn't cause parse
> >errors, so I guess syntax is fine.
> > 
> >  meta/recipes-connectivity/connman/connman.inc | 95 
> > +--
> >  1 file changed, 32 insertions(+), 63 deletions(-)
> > 
> > diff --git a/meta/recipes-connectivity/connman/connman.inc 
> > b/meta/recipes-connectivity/connman/connman.inc
> > index 35a7eed..671d533 100644
> > --- a/meta/recipes-connectivity/connman/connman.inc
> > +++ b/meta/recipes-connectivity/connman/connman.inc
> > @@ -46,24 +46,17 @@ PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, 
> > wpa-supplicant, wpa-suppli
> >  PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, ${BLUEZ}, 
> > ${BLUEZ}"
> >  PACKAGECONFIG[3g] = "--enable-ofono, --disable-ofono, ofono, ofono"
> >  PACKAGECONFIG[tist] = "--enable-tist,--disable-tist,"
> > -PACKAGECONFIG[openvpn] = "--enable-openvpn 
> > --with-openvpn=${sbindir}/openvpn,--disable-openvpn,,openvpn"
> > -PACKAGECONFIG[vpnc] = "--enable-vpnc 
> > --with-vpnc=${sbindir}/vpnc,--disable-vpnc,,vpnc"
> > -PACKAGECONFIG[l2tp] = "--enable-l2tp 
> > --with-l2tp=${sbindir}/xl2tpd,--disable-l2tp,,xl2tpd"
> > -PACKAGECONFIG[pptp] = "--enable-pptp 
> > --with-pptp=${sbindir}/pptp,--disable-pptp,,pptp-linux"
> > +PACKAGECONFIG[openvpn] = "--enable-openvpn 
> > --with-openvpn=${sbindir}/openvpn,--disable-openvpn"
> > +PACKAGECONFIG[vpnc] = "--enable-vpnc 
> > --with-vpnc=${sbindir}/vpnc,--disable-vpnc"
> > +PACKAGECONFIG[l2tp] = "--enable-l2tp,--disable-l2tp"
> > +PACKAGECONFIG[pptp] = "--enable-pptp,--disable-pptp"
> >  # WISPr support for logging into hotspots, requires TLS
> >  PACKAGECONFIG[wispr] = "--enable-wispr,--disable-wispr,gnutls,"
> >  
> >  INITSCRIPT_NAME = "connman"
> >  INITSCRIPT_PARAMS = "start 05 5 2 3 . stop 22 0 1 6 ."
> >  
> > -python __anonymous () {
> > -systemd_packages = "${PN}"
> > -pkgconfig = d.getVar('PACKAGECONFIG', True)
> > -if ('openvpn' or 'vpnc' or 'l2tp' or 'pptp') in pkgconfig.split():
> > -systemd_packages += " ${PN}-vpn"
> > -d.setVar('SYSTEMD_PACKAGES', systemd_packages)
> > -}
> > -
> > +SYSTEMD_PACKAGES = "${PN} ${PN}-vpn"
> >  SYSTEMD_SERVICE_${PN} = "connman.service"
> >  SYSTEMD_SERVICE_${PN}-vpn = "connman-vpn.service"
> >  SYSTEMD_SERVICE_${PN}-wait-online = "connman-wait-online.service"
> > @@ -103,36 +96,6 @@ RDEPENDS_${PN} = "\
> > dbus \
> > "
> >  
> > -PACKAGES_DYNAMIC += "^${PN}-plugin-.*"
> > -
> > -def add_rdepends(bb, d, file, pkg, depmap, multilib_prefix, 
> > add_insane_skip):
> > -plugintype = pkg.split( '-' )[-1]
> > -if plugintype in depmap:
> > -rdepends = map(lambda x: multilib_prefix + x, \
> > -   depmap[plugintype].split())
> > -d.setVar("RDEPENDS_%s" % pkg, " ".join(rdepends))
> > -if add_insane_skip:
> > -d.appendVar("INSANE_SKIP_%s" % pkg, "dev-so")
> > -
> > -python populate_packages_prepend() {
> > -depmap = dict(pppd="ppp")
> > -multilib_prefix = (d.getVar("MLPREFIX", True) or "")
> > -
> > -hook = lambda file,pkg,x,y,z: \
> > -add_rdepends(bb, d, file, pkg, depmap, multilib_prefix, False)
> > -plugin_dir = d.expand('${libdir}/connman/plugins/')
> > -plugin_name = d.expand('${PN}-plugin-%s')
> > -do_split_packages(d, plugin_dir, '^(.*).so$', plugin_name, \
> > -'${PN} plugin for %s', extra_depends='', hook=hook, prepend=True )
> > -
> > -hook = lambda file,pkg,x,y,z: \
> > -add_rdepends(bb, d, file, pkg, depmap, multilib_prefix, True)
> > -plugin_dir = d.expand('${libdir}/connman/plugins-vpn/')
> > -plugin_name = d.expand('${PN}-plugin-vpn-%s')
> > -do_split_packages(d, plugin_dir, '^(.*).so$', plugin_name, \
> > -'${PN} VPN plugin for %s', extra_depends='', hook=hook, 
> > prepend=True )
> > -}
> > -
> >  PACKAGES =+ "${PN}-tools ${PN}

Re: [OE-core] GUI based images

[Ian Arkver]

On 09/05/17 09:44, Alex J Lennon wrote:



On 09/05/17 09:05, Alexander Kanavin wrote:

On 05/09/2017 01:15 AM, Paul Eggleton wrote:

LXDE in particular is Gtk2 based, it's no longer being developed, and
has been superseded by LXQt. So it's a non-starter (and so is LXQt,
which should be clear from its name :).


FWIW I think this is a little short-sighted. Why are we ruling out Qt 
exactly?


We would first have to agree that Qt5 belongs in oe-core with 
appropriate level of maintenance and QA, and that it's okay to add 
half an hour or more to the building time of a standard GUI image.


From the screenshots of LxQT, it looks like yet another Win95 clone 
meant strictly for desktop use that would certainly scale poorly to 
small resolution screens. Who would be the target audience for it in 
the embedded space? For the purposes of 'engineering UI', Sato is 
fine, and we don't need something else.


Alex


fwiw. I would love to be able to develop devices like those pictured 
below, which I believe are based on Qt for Device Creation.


https://d33sqmjvzgs8hq.cloudfront.net/wp-content/uploads/2014/08/devices.png 



ref: https://www.qt.io/qt-for-device-creation/

Cheers,

Alex



They have their own meta-b2qt layer for that. See "Embedded 
documentation" and "Building Your Own Embedded Linux Image" from that

page.

It's not an OE-core thing, imho.

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

Re: [OE-core] [PATCH 1/1] cve-check.bbclass: make warning contain CVE IDs

[Joshua Lock]

On Tue, 2017-05-09 at 17:13 +0800, Chen Qi wrote:
> When warning users about unpatched CVE, we'd better put CVE IDs into
> the warning message, so that it would be more straight forward for
> the
> user to know which CVEs are not patched.
> 
> So instead of:
>   WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE, for
> more information check /path/to/workdir/cve/cve.log.
> We should have:
>   WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE (CVE-
> 2017-7869), for more information check /path/to/workdir/cve/cve.log.
> 
> Signed-off-by: Chen Qi 
> ---
>  meta/classes/cve-check.bbclass | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-
> check.bbclass
> index 0e4294f..496d744 100644
> --- a/meta/classes/cve-check.bbclass
> +++ b/meta/classes/cve-check.bbclass
> @@ -234,7 +234,8 @@ def cve_write_data(d, patched, unpatched,
> cve_data):
>  cve_file = d.getVar("CVE_CHECK_LOCAL_FILE")
>  nvd_link = "https://web.nvd.nist.gov/view/vuln/detail?vulnId=";
>  write_string = ""
> -first_alert = True
> +has_unpatched_cve = False
> +unpatched_cves = []
>  bb.utils.mkdirhier(d.getVar("CVE_CHECK_LOCAL_DIR"))
>  
>  for cve in sorted(cve_data):
> @@ -244,15 +245,17 @@ def cve_write_data(d, patched, unpatched,
> cve_data):
>  if cve in patched:
>  write_string += "CVE STATUS: Patched\n"
>  else:
> +unpatched_cves.append(cve)
>  write_string += "CVE STATUS: Unpatched\n"
> -if first_alert:
> -bb.warn("Found unpatched CVE, for more information
> check %s" % cve_file)
> -first_alert = False
> +has_unpatched_cve = True
>  write_string += "CVE SUMMARY: %s\n" %
> cve_data[cve]["summary"]
>  write_string += "CVSS v2 BASE SCORE: %s\n" %
> cve_data[cve]["score"]
>  write_string += "VECTOR: %s\n" % cve_data[cve]["vector"]
>  write_string += "MORE INFORMATION: %s%s\n\n" % (nvd_link,
> cve)
>  
> +if has_unpatched_cve:

There's no need for the has_unpatched_cve variable, you can just test
whether the unpatched_cves list is empty:

>>> foo = []
>>> bar = [1, 2, 3]
>>> if foo:
...   print("foo")
... 
>>> if bar:
...   print("bar")
... 
bar

Your conditional can just be:

  + if unpatched_cve:
> +bb.warn("Found unpatched CVE (%s), for more information
> check %s" % (" ".join(unpatched_cves),cve_file))
> +
>  with open(cve_file, "w") as f:
>  bb.note("Writing file %s with CVE information" % cve_file)
>  f.write(write_string)
> -- 
> 1.9.1
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] cve-check.bbclass: make warning contain CVE IDs

[Chen Qi]

When warning users about unpatched CVE, we'd better put CVE IDs into
the warning message, so that it would be more straight forward for the
user to know which CVEs are not patched.

So instead of:
  WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE, for more 
information check /path/to/workdir/cve/cve.log.
We should have:
  WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE (CVE-2017-7869), 
for more information check /path/to/workdir/cve/cve.log.

Signed-off-by: Chen Qi 
---
 meta/classes/cve-check.bbclass | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 0e4294f..496d744 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -234,7 +234,8 @@ def cve_write_data(d, patched, unpatched, cve_data):
 cve_file = d.getVar("CVE_CHECK_LOCAL_FILE")
 nvd_link = "https://web.nvd.nist.gov/view/vuln/detail?vulnId=";
 write_string = ""
-first_alert = True
+has_unpatched_cve = False
+unpatched_cves = []
 bb.utils.mkdirhier(d.getVar("CVE_CHECK_LOCAL_DIR"))
 
 for cve in sorted(cve_data):
@@ -244,15 +245,17 @@ def cve_write_data(d, patched, unpatched, cve_data):
 if cve in patched:
 write_string += "CVE STATUS: Patched\n"
 else:
+unpatched_cves.append(cve)
 write_string += "CVE STATUS: Unpatched\n"
-if first_alert:
-bb.warn("Found unpatched CVE, for more information check %s" % 
cve_file)
-first_alert = False
+has_unpatched_cve = True
 write_string += "CVE SUMMARY: %s\n" % cve_data[cve]["summary"]
 write_string += "CVSS v2 BASE SCORE: %s\n" % cve_data[cve]["score"]
 write_string += "VECTOR: %s\n" % cve_data[cve]["vector"]
 write_string += "MORE INFORMATION: %s%s\n\n" % (nvd_link, cve)
 
+if has_unpatched_cve:
+bb.warn("Found unpatched CVE (%s), for more information check %s" % (" 
".join(unpatched_cves),cve_file))
+
 with open(cve_file, "w") as f:
 bb.note("Writing file %s with CVE information" % cve_file)
 f.write(write_string)
-- 
1.9.1

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

[OE-core] [PATCH 0/1] cve-check.bbclass: make warning contain CVE IDs

[Chen Qi]

The following changes since commit 381897c64069ea43d595380a3ae913bcc79cf7e1:

  build-appliance-image: Update to master head revision (2017-05-01 08:56:47 
+0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/cve-check-warning
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/cve-check-warning

Chen Qi (1):
  cve-check.bbclass: make warning contain CVE IDs

 meta/classes/cve-check.bbclass | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

-- 
1.9.1

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

Re: [OE-core] [[PATCH v2] kernel-fitimage: fix ${KERNEL_DEVICETREE} includes subdirectory issue.

[Andreas Oberritter]

Dear Chunrong Guo,

you don't need to repost the same patch over and over again. Please consider
my reply to your first submission of v2.

http://lists.openembedded.org/pipermail/openembedded-core/2017-May/136345.html

Regards,
Andreas

P.S.: The subject contains a superflous bracket.



On Tue, 9 May 2017 15:38:59 +0800
Chunrong Guo  wrote:

> From: Chunrong Guo 
> 
> * For example:
>   KERNEL_DEVICETREE ?= "freescale/fsl-ls1046a-rdb.dtb"
> 
>   ${DTB}= "freescale/fsl-ls1046a-rdb.dtb"
> 
>   but only the dtb name should be used.
> 
> * Support "ext2.gz " filesystems
> 
> * Support mutiple KERNEL_IMAGETYPE
>   For example:
>KERNEL_IMAGETYPE = "Image"  or  KERNEL_IMAGETYPE = "zImage"
> 
> Signed-off-by: Chunrong Guo 
> ---
>  meta/classes/kernel-fitimage.bbclass | 15 ---
>  1 file changed, 4 insertions(+), 11 deletions(-)
> 
> diff --git a/meta/classes/kernel-fitimage.bbclass 
> b/meta/classes/kernel-fitimage.bbclass
> index 2630b47..63f03a5 100644
> --- a/meta/classes/kernel-fitimage.bbclass
> +++ b/meta/classes/kernel-fitimage.bbclass
> @@ -10,7 +10,7 @@ python __anonymous () {
>  if d.getVar("UBOOT_ARCH") == "x86":
>  replacementtype = "bzImage"
>  else:
> -replacementtype = "zImage"
> +replacementtype = d.getVar("KERNEL_IMAGETYPE")
>  
>   # Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
>   # to kernel.bbclass . We have to override it, since we pack zImage
> @@ -342,15 +342,8 @@ fitimage_assemble() {
>   if [ -n "${KERNEL_DEVICETREE}" ]; then
>   dtbcount=1
>   for DTB in ${KERNEL_DEVICETREE}; do
> - if echo ${DTB} | grep -q '/dts/'; then
> - bbwarn "${DTB} contains the full path to the 
> the dts file, but only the dtb name should be used."
> - DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
> - fi
> - DTB_PATH="arch/${ARCH}/boot/dts/${DTB}"
> - if [ ! -e "${DTB_PATH}" ]; then
> - DTB_PATH="arch/${ARCH}/boot/${DTB}"
> - fi
> -
> +DTB=`basename ${DTB}`
> + DTB_PATH=`find arch/${ARCH}/boot -name "${DTB}"` 
>   DTBS="${DTBS} ${DTB}"
>   fitimage_emit_section_dtb ${1} ${DTB} ${DTB_PATH}
>   done
> @@ -369,7 +362,7 @@ fitimage_assemble() {
>   #
>   if [ "x${ramdiskcount}" = "x1" ] ; then
>   # Find and use the first initramfs image archive type we find
> - for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz cpio; do
> + for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz cpio 
> ext2.gz; do
>   
> initramfs_path="${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.${img}"
>   echo "Using $initramfs_path"
>   if [ -e "${initramfs_path}" ]; then

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

Re: [OE-core] GUI based images

[Alex J Lennon]

On 09/05/17 09:05, Alexander Kanavin wrote:

On 05/09/2017 01:15 AM, Paul Eggleton wrote:

LXDE in particular is Gtk2 based, it's no longer being developed, and
has been superseded by LXQt. So it's a non-starter (and so is LXQt,
which should be clear from its name :).


FWIW I think this is a little short-sighted. Why are we ruling out Qt 
exactly?


We would first have to agree that Qt5 belongs in oe-core with 
appropriate level of maintenance and QA, and that it's okay to add 
half an hour or more to the building time of a standard GUI image.


From the screenshots of LxQT, it looks like yet another Win95 clone 
meant strictly for desktop use that would certainly scale poorly to 
small resolution screens. Who would be the target audience for it in 
the embedded space? For the purposes of 'engineering UI', Sato is 
fine, and we don't need something else.


Alex


fwiw. I would love to be able to develop devices like those pictured 
below, which I believe are based on Qt for Device Creation.


https://d33sqmjvzgs8hq.cloudfront.net/wp-content/uploads/2014/08/devices.png

ref: https://www.qt.io/qt-for-device-creation/

Cheers,

Alex

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

Re: [OE-core] GUI based images

[Alexander Kanavin]

On 05/09/2017 01:50 AM, Khem Raj wrote:

A general usecase is that someone takes the reference and tweaks it to
meet the needs of a product quickly. For such usecases, it would be good to
consider the most widely used UI framework in embedded space. I
personally don't know how much sato is deployed but QT based systems
are quite widely deployed as far as I know. I think users can drive maximum
out of the testing and stabilization we do if they were using the reference
software as much as possible.


Qt itself does not provide a UI, so we would need to find an appropriate 
qt-based replacement for Sato that has the same characteristics and is 
suitable as an 'engineering UI'. What is your suggestion for that?


I personally think meta-qt5 works fine; it's only missing a reference UI 
environment. Why not add LxQt to that layer?



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

Re: [OE-core] GUI based images

[Alexander Kanavin]

On 05/09/2017 01:15 AM, Paul Eggleton wrote:

LXDE in particular is Gtk2 based, it's no longer being developed, and
has been superseded by LXQt. So it's a non-starter (and so is LXQt,
which should be clear from its name :).


FWIW I think this is a little short-sighted. Why are we ruling out Qt exactly?


We would first have to agree that Qt5 belongs in oe-core with 
appropriate level of maintenance and QA, and that it's okay to add half 
an hour or more to the building time of a standard GUI image.


From the screenshots of LxQT, it looks like yet another Win95 clone 
meant strictly for desktop use that would certainly scale poorly to 
small resolution screens. Who would be the target audience for it in the 
embedded space? For the purposes of 'engineering UI', Sato is fine, and 
we don't need something else.


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

[OE-core] [[PATCH v2] kernel-fitimage: fix ${KERNEL_DEVICETREE} includes subdirectory issue.

[Chunrong Guo]

From: Chunrong Guo 

* For example:
  KERNEL_DEVICETREE ?= "freescale/fsl-ls1046a-rdb.dtb"

  ${DTB}= "freescale/fsl-ls1046a-rdb.dtb"

  but only the dtb name should be used.

* Support "ext2.gz " filesystems

* Support mutiple KERNEL_IMAGETYPE
  For example:
   KERNEL_IMAGETYPE = "Image"  or  KERNEL_IMAGETYPE = "zImage"

Signed-off-by: Chunrong Guo 
---
 meta/classes/kernel-fitimage.bbclass | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 2630b47..63f03a5 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -10,7 +10,7 @@ python __anonymous () {
 if d.getVar("UBOOT_ARCH") == "x86":
 replacementtype = "bzImage"
 else:
-replacementtype = "zImage"
+replacementtype = d.getVar("KERNEL_IMAGETYPE")
 
# Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
# to kernel.bbclass . We have to override it, since we pack zImage
@@ -342,15 +342,8 @@ fitimage_assemble() {
if [ -n "${KERNEL_DEVICETREE}" ]; then
dtbcount=1
for DTB in ${KERNEL_DEVICETREE}; do
-   if echo ${DTB} | grep -q '/dts/'; then
-   bbwarn "${DTB} contains the full path to the 
the dts file, but only the dtb name should be used."
-   DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
-   fi
-   DTB_PATH="arch/${ARCH}/boot/dts/${DTB}"
-   if [ ! -e "${DTB_PATH}" ]; then
-   DTB_PATH="arch/${ARCH}/boot/${DTB}"
-   fi
-
+DTB=`basename ${DTB}`
+   DTB_PATH=`find arch/${ARCH}/boot -name "${DTB}"` 
DTBS="${DTBS} ${DTB}"
fitimage_emit_section_dtb ${1} ${DTB} ${DTB_PATH}
done
@@ -369,7 +362,7 @@ fitimage_assemble() {
#
if [ "x${ramdiskcount}" = "x1" ] ; then
# Find and use the first initramfs image archive type we find
-   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz cpio; do
+   for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz cpio 
ext2.gz; do

initramfs_path="${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.${img}"
echo "Using $initramfs_path"
if [ -e "${initramfs_path}" ]; then
-- 
1.9.0

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