date:20180814

Re: [OE-core] adding python modules

2018-08-14 Thread Alexander Kanavin

Simple - add python3-modules to the packagegroup. Sadly this seems to
be 'common knowledge' that is poorly documented.

Alex

2018-08-14 0:51 GMT+02:00 bhas_purk :
> Hello,
> I am new to yocto, and we are using this for an Intel SOC.
> I am creating a console-image, and wanted to get python3 in the rootfs.
>
> So I added python3 in the recipe file -
> layers/meta-openembedded/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
> This gave me python3 in the rootfs and I can run ptyhon3. So that is great!
>
>
> Now I would like to add some modules to python such that they are built in,
> and I dont have to do a pip install for the modules.
>
> I see that there is a script file which generates the manifest for all
> modules will be there.
> openembedded-core/scripts/contrib/python/generate-manifest-3.5.py
>
>
> I would like to edit this file to some python modules, and am wondering how.
>
> For example, one of the existing modules in the script is defined like this-
>   m.addPackage( "${PN}-argparse", "Python command line argument parser",
> "${PN}-core ${PN}-codecs ${PN}-textutils",
> "argparse.*" )
>
>
> So my question is, for the modules I would like to add, how do I know the
> dependencies etc? And more importantly, is this the right way to add modules
> to python3 in the rootfs.
>
>
> Thank you
> Bhaskar
>
>
>
>
>
> --
> ___
> 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] [PATCH 1/1] allarch: disable allarch when multilib is used

2018-08-14 Thread Kang Kai


On 2018年08月12日 00:10, richard.pur...@linuxfoundation.org wrote:

On Fri, 2018-08-10 at 16:14 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

Some allarch packages rdepends non-allarch packages. When multilib is
used, it doesn't expand the dependency chain correctly, e.g.

core-image-sato -> ca-certificates(allarch) -> openssl

we expect dependency chain for lib32-core-image-sato:

lib32-core-image-sato -> ca-certificates(allarch) -> lib32-openssl

it should install lib32-openssl for ca-certificates but openssl is
still wrongly imported.

Disable allarch when multilib is used.

Signed-off-by: Kai Kang 
---
  meta/classes/allarch.bbclass | 4 
  meta/classes/icecc.bbclass   | 2 +-
  meta/classes/multilib.bbclass| 3 ++-
  meta/classes/multilib_global.bbclass | 4 +---
  meta/classes/package.bbclass | 9 ++---
  meta/classes/staging.bbclass | 2 +-
  6 files changed, 15 insertions(+), 9 deletions(-)

With this applied, "bitbake nativesdk-dbus" fails to build since
it can't find the extra autoconf macros from an allarch recipe in
DEPENDS.

e.g. https://autobuilder.yocto.io/builders/nightly-arm/builds/1262/step
s/Building%20Toolchain%20Images/logs/stdio


The autoconf-archive-native is not installed to recipe sysroot native. 
Some debug info shows the task do_populate_sysroot
of autoconf-archive-native is not executed. And so do some other 
packages(tasks).


DEBUG: Stampfile 
/buildarea/kkang/yocto/noarch-verify-build-Aug13/tmp/stamps/x86_64-linux/autoconf-archive-native/2018.03.13-r0.do_populate_sysroot_setscene.41bdb37fee4fb443715e1c84a5de281f 
not available
DEBUG: Normal stamp current for task 
virtual:native:/buildarea/kkang/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb:do_populate_sysroot
DEBUG: Found task 
virtual:native:/buildarea/kkang/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb:do_populate_sysroot 
which could be accelerated


I have been working on it but not get the root cause yet.

Sorry for the inconvenience.

Regards,
Kai




Cheers,

Richard



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 1/2] cpan.bbclass: adopt to recent EU::MM

2018-08-14 Thread Jens Rehsack

Hi Ross,

I did on August, 8th - but I don't see it in master-next or any issue reported 
on that...
Did it arrive?

Cheers,
Jens

> Am 06.08.2018 um 14:00 schrieb Burton, Ross :
> 
> Hi Jens,
> 
> Can you use git-send-email, as the patch gets corrupted by Apple Mail.
> 
> Ross
> 
> On 2 August 2018 at 09:20, Jens Rehsack  wrote:
>> The modern the time, the improvements in ExtUtils::MakeMaker.
>> 
>> Nowadays, .packlist and perllocal.pod aren't touched anymore when appropriate
>> flags set during configure stage. Controlling the flags globally avoids
>> dual-life recipes need share patching.
>> 
>> Further: remove prepending ${PERL_ARCHLIB} in PERL5LIB - it's wrong (search
>> order is site_lib, vendor_lib, core) - and ${PERL_ARCHLIB} contains core
>> libpath only ...
>> 
>> Signed-off-by: Jens Rehsack 
>> ---
>> meta/classes/cpan.bbclass | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/meta/classes/cpan.bbclass b/meta/classes/cpan.bbclass
>> index 8e079e0d55..926c6358a6 100644
>> --- a/meta/classes/cpan.bbclass
>> +++ b/meta/classes/cpan.bbclass
>> @@ -16,8 +16,7 @@ export PERL_ARCHLIB = 
>> "${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version
>> export PERLHOSTLIB = 
>> "${STAGING_LIBDIR_NATIVE}/perl-native/perl/${@get_perl_version(d)}/"
>> 
>> cpan_do_configure () {
>> -   export PERL5LIB="${PERL_ARCHLIB}"
>> -   yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor 
>> ${EXTRA_CPANFLAGS}
>> +   yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor 
>> NO_PERLLOCAL=1 NO_PACKLIST=1 ${EXTRA_CPANFLAGS}
>> 
>># Makefile.PLs can exit with success without generating a
>># Makefile, e.g. in cases of missing configure time
>> --
>> 2.17.1
>> 
>> 
>> --
>> Jens Rehsack - rehs...@gmail.com
>> 
>> 
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> 

--
Jens Rehsack - rehs...@gmail.com



signature.asc
Description: Message signed with OpenPGP
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] adding python modules

2018-08-14 Thread Burton, Ross

If you're referring to the standard library modules then they should
be installed for you as when you say to install python3, you actually
get python3-modules.

If you want to install further non-standard modules then just add them
to the image, for example python3-pip will give you pip.

Ross

On 13 August 2018 at 23:51, bhas_purk  wrote:
> Hello,
> I am new to yocto, and we are using this for an Intel SOC.
> I am creating a console-image, and wanted to get python3 in the rootfs.
>
> So I added python3 in the recipe file -
> layers/meta-openembedded/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
> This gave me python3 in the rootfs and I can run ptyhon3. So that is great!
>
>
> Now I would like to add some modules to python such that they are built in,
> and I dont have to do a pip install for the modules.
>
> I see that there is a script file which generates the manifest for all
> modules will be there.
> openembedded-core/scripts/contrib/python/generate-manifest-3.5.py
>
>
> I would like to edit this file to some python modules, and am wondering how.
>
> For example, one of the existing modules in the script is defined like this-
>   m.addPackage( "${PN}-argparse", "Python command line argument parser",
> "${PN}-core ${PN}-codecs ${PN}-textutils",
> "argparse.*" )
>
>
> So my question is, for the modules I would like to add, how do I know the
> dependencies etc? And more importantly, is this the right way to add modules
> to python3 in the rootfs.
>
>
> Thank you
> Bhaskar
>
>
>
>
>
> --
> ___
> 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] [PATCH 1/2] cpan.bbclass: adopt to recent EU::MM

2018-08-14 Thread Richard Purdie

On Tue, 2018-08-14 at 12:02 +0200, Jens Rehsack wrote:
> I did on August, 8th - but I don't see it in master-next or any issue
> reported on that...
> Did it arrive?

I reported problems:

http://lists.openembedded.org/pipermail/openembedded-core/2018-August/153792.html

Basically the -native version doesn't build due to the changes to make
the target version work.

Cheers,

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

[OE-core] [PATCH] systemd: fixes for the compatibility interface

2018-08-14 Thread Andrej Valek

Use a heap allocated string to set arg_ifname, since a stack allocated
one would be lost after the function returns. (This last one broke the
case where an interface name was suffixed with a dot, such as in
`resolvconf -a tap0.dhcp`.)

Signed-off-by: Andrej Valek 
Signed-off-by: Simon Ausserlechner 
---
 ...onf-fixes-for-the-compatibility-interface.patch | 58 ++
 meta/recipes-core/systemd/systemd_239.bb   |  1 +
 2 files changed, 59 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0023-resolvconf-fixes-for-the-compatibility-interface.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0023-resolvconf-fixes-for-the-compatibility-interface.patch
 
b/meta/recipes-core/systemd/systemd/0023-resolvconf-fixes-for-the-compatibility-interface.patch
new file mode 100644
index 00..2f3e776aa0
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0023-resolvconf-fixes-for-the-compatibility-interface.patch
@@ -0,0 +1,58 @@
+systemd-239: fixes for the compatibility interface
+
+[No upstream tracking] -- https://github.com/systemd/systemd/issues/9423
+
+resolvconf-compat: use compat_main() when called as `resolvconf`,
+since the interface is closer to that of `systemd-resolve`.
+
+Use a heap allocated string to set arg_ifname, since a stack allocated
+one would be lost after the function returns. (This last one broke the
+case where an interface name was suffixed with a dot, such as in
+`resolvconf -a tap0.dhcp`.)
+
+Tested:
+  $ build/resolvconf -a nonexistent.abc https://github.com/systemd/systemd/commit/5a01b3f35d7b6182c78b6973db8d99bdabd4f9c3]
+bug: 9423
+Signed-off-by: Simon Ausserlechner 
+
+diff --git a/src/resolve/resolvconf-compat.c b/src/resolve/resolvconf-compat.c
+index d7e68003e..072345894 100644
+--- a/src/resolve/resolvconf-compat.c
 b/src/resolve/resolvconf-compat.c
+@@ -53,6 +53,8 @@ static int parse_nameserver(const char *string) {
+ 
+ if (strv_push(&arg_set_dns, word) < 0)
+ return log_oom();
++
++word = NULL;
+ }
+ 
+ return 0;
+@@ -202,7 +204,7 @@ int resolvconf_parse_argv(int argc, char *argv[]) {
+ 
+ dot = strchr(argv[optind], '.');
+ if (dot) {
+-iface = strndupa(argv[optind], dot - argv[optind]);
++iface = strndup(argv[optind], dot - argv[optind]);
+ log_debug("Ignoring protocol specifier '%s'.", dot + 1);
+ } else
+ iface = argv[optind];
+diff --git a/src/resolve/resolvectl.c b/src/resolve/resolvectl.c
+index e96c13fea..e9e395e3e 100644
+--- a/src/resolve/resolvectl.c
 b/src/resolve/resolvectl.c
+@@ -3092,7 +3092,7 @@ int main(int argc, char **argv) {
+ goto finish;
+ }
+ 
+-if (streq(program_invocation_short_name, "systemd-resolve"))
++if (STR_IN_SET(program_invocation_short_name, "systemd-resolve", 
"resolvconf"))
+ r = compat_main(argc, argv, bus);
+ else
+ r = native_main(argc, argv, bus);
+-- 
+2.11.0
+
diff --git a/meta/recipes-core/systemd/systemd_239.bb 
b/meta/recipes-core/systemd/systemd_239.bb
index 67f6117a2a..84906f97b7 100644
--- a/meta/recipes-core/systemd/systemd_239.bb
+++ b/meta/recipes-core/systemd/systemd_239.bb
@@ -29,6 +29,7 @@ SRC_URI += "file://touchscreen.rules \

file://0001-login-use-parse_uid-when-unmounting-user-runtime-dir.patch \
file://0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch \

file://0022-build-sys-Detect-whether-struct-statx-is-defined-in-.patch \
+   file://0023-resolvconf-fixes-for-the-compatibility-interface.patch \
"
 SRC_URI_append_qemuall = " 
file://0001-core-device.c-Change-the-default-device-timeout-to-2.patch"
 
-- 
2.11.0

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

Re: [OE-core] [PATCH v3] runqemu: exit gracefully with an error message if qemu system is not evaluated

2018-08-14 Thread Peter Kjellerstedt

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Jagadeesh
> Krishnanjanappa
> Sent: den 14 augusti 2018 04:52
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH v3] runqemu: exit gracefully with an error
> message if qemu system is not evaluated
> 
> It solves below error:
> -- snip --
> return 'qemu-system-%s' % qbsys
> UnboundLocalError: local variable 'qbsys' referenced before assignment
> -- snip --
> 
> [YOCTO #12846]
> 
> * v3 changes:
>   Added yocto bugzilla ID in the required format

The two lines above belong after the --- line below as they are only 
relevant during the patch submission process, not once the change is 
integrated.

> 
> Signed-off-by: Jagadeesh Krishnanjanappa 
> ---
>  scripts/runqemu | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/scripts/runqemu b/scripts/runqemu
> index f52b9a8..409d17c 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -1118,6 +1118,11 @@ class BaseConfig(object):
>  qbsys = 'riscv64'
>  elif mach == 'qemuriscv32':
>  qbsys = 'riscv32'
> +else:
> +logger.error("Unable to determine QEMU PC System emulator
> for %s machine." % mach)
> +logger.error("As %s is not among valid QEMU machines such
> as," % mach)
> +logger.error("qemux86-64, qemux86, qemuarm64, qemuarm,
> qemumips64, qemumips64el, qemumipsel, qemumips, qemuppc")
> +raise RunQemuError("Set qb_system_name with suitable QEMU
> PC System emulator in .*qemuboot.conf.")
> 
>  return 'qemu-system-%s' % qbsys
> 
> --
> 1.8.3.1
> 
> --
> ___
> 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] weston: add dependency on virtual/libgbm for kms PACKAGECONFIG

2018-08-14 Thread Martin Jansa

* gbm is checked in configure.ac:

AC_ARG_ENABLE(drm-compositor, [  --enable-drm-compositor],,
  enable_drm_compositor=yes)
AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test x$enable_drm_compositor = xyes)
if test x$enable_drm_compositor = xyes; then
  AC_DEFINE([BUILD_DRM_COMPOSITOR], [1], [Build the DRM compositor])
  PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm mtdev 
>= 1.1.0])
  PKG_CHECK_MODULES(DRM_COMPOSITOR_GBM, [gbm >= 10.2],
[AC_DEFINE([HAVE_GBM_FD_IMPORT], 1, [gbm supports dmabuf 
import])],
[AC_MSG_WARN([gbm does not support dmabuf import, will omit 
that capability])])
fi

Signed-off-by: Martin Jansa 
---
 meta/recipes-graphics/wayland/weston_4.0.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/wayland/weston_4.0.0.bb 
b/meta/recipes-graphics/wayland/weston_4.0.0.bb
index e78b0d9194..3d192cf00a 100644
--- a/meta/recipes-graphics/wayland/weston_4.0.0.bb
+++ b/meta/recipes-graphics/wayland/weston_4.0.0.bb
@@ -43,7 +43,7 @@ PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 
'wayland', 'kms fbdev
 # Compositor choices
 #
 # Weston on KMS
-PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm 
udev virtual/mesa mtdev"
+PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm 
udev virtual/mesa virtual/libgbm mtdev"
 # Weston on Wayland (nested Weston)
 PACKAGECONFIG[wayland] = 
"--enable-wayland-compositor,--disable-wayland-compositor,virtual/mesa"
 # Weston on X11
-- 
2.17.1

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

Re: [OE-core] [PATCH 1/2] cpan.bbclass: adopt to recent EU::MM

2018-08-14 Thread Jens Rehsack



> Am 14.08.2018 um 12:17 schrieb Richard Purdie 
> :
> 
> On Tue, 2018-08-14 at 12:02 +0200, Jens Rehsack wrote:
>> I did on August, 8th - but I don't see it in master-next or any issue
>> reported on that...
>> Did it arrive?
> 
> I reported problems:
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2018-August/153792.html
> 
> Basically the -native version doesn't build due to the changes to make
> the target version work.

Unfortunately I didn't realize that ... Checking soon.

I expect some similar patch as the target version needed is required to the 
-native one - Devel::CheckLib is evil :/

Cheers
--
Jens Rehsack - rehs...@gmail.com



signature.asc
Description: Message signed with OpenPGP
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] pcmciautils: remove from oe-core

2018-08-14 Thread Ross Burton

PCMCIA is pretty rare these days, so now that the recipe is in meta-oe we can
remove it from oe-core.

Signed-off-by: Ross Burton 
---
 meta/conf/distro/include/maintainers.inc   |   1 -
 .../pcmciautils-018/lex_sys_types.patch|  21 -
 .../pcmciautils/pcmciautils-018/makefile_fix.patch | 101 -
 .../pcmciautils-018/makefile_race.patch|  29 --
 meta/recipes-bsp/pcmciautils/pcmciautils.inc   |  34 ---
 meta/recipes-bsp/pcmciautils/pcmciautils_018.bb|  11 ---
 6 files changed, 197 deletions(-)
 delete mode 100644 
meta/recipes-bsp/pcmciautils/pcmciautils-018/lex_sys_types.patch
 delete mode 100644 
meta/recipes-bsp/pcmciautils/pcmciautils-018/makefile_fix.patch
 delete mode 100644 
meta/recipes-bsp/pcmciautils/pcmciautils-018/makefile_race.patch
 delete mode 100644 meta/recipes-bsp/pcmciautils/pcmciautils.inc
 delete mode 100644 meta/recipes-bsp/pcmciautils/pcmciautils_018.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 08f8c46ff47..0d1c72a85fe 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -519,7 +519,6 @@ RECIPE_MAINTAINER_pn-patchelf = "Richard Purdie 

-Upstream-Status: Pending
-Index: pcmciautils-018/src/lex_config.l
-===
 pcmciautils-018.orig/src/lex_config.l
-+++ pcmciautils-018/src/lex_config.l
-@@ -22,6 +22,7 @@
- #include 
- #include 
- #include 
-+#include 
- 
- #ifdef HAS_WORDEXP
- #include 
diff --git a/meta/recipes-bsp/pcmciautils/pcmciautils-018/makefile_fix.patch 
b/meta/recipes-bsp/pcmciautils/pcmciautils-018/makefile_fix.patch
deleted file mode 100644
index 7b0ce21194c..000
--- a/meta/recipes-bsp/pcmciautils/pcmciautils-018/makefile_fix.patch
+++ /dev/null
@@ -1,101 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-Hardcoded paths are bad...
-This lets us use the install from OE's native sysroot
-rebase the patch to 018, removing hardcoded path for true
-as well. Removing of -D in install invocation is a little
-questionable, is it some GNU extention?
-
--Khem Raj 
-
-Index: pcmciautils-018/Makefile
-===
 pcmciautils-018.orig/Makefile
-+++ pcmciautils-018/Makefile
-@@ -76,7 +76,7 @@ sbindir =${exec_prefix}/sbin
- mandir =  ${prefix}/usr/share/man
- udevdir = ${prefix}/lib/udev
- 
--INSTALL = /usr/bin/install -c
-+INSTALL = install -c
- INSTALL_PROGRAM = ${INSTALL}
- INSTALL_DATA  = ${INSTALL} -m 644
- INSTALL_SCRIPT = ${INSTALL_PROGRAM}
-@@ -180,7 +180,7 @@ endif
- # if DEBUG is enabled, then we do not strip or optimize
- ifeq ($(strip $(DEBUG)),true)
-   CFLAGS  += -O1 -g -DDEBUG -D_GNU_SOURCE
--  STRIPCMD = /bin/true -Since_we_are_debugging
-+  STRIPCMD = true -Since_we_are_debugging
- else
-   CFLAGS  += $(OPTIMIZATION) -fomit-frame-pointer -D_GNU_SOURCE
-   STRIPCMD = $(STRIP) -s --remove-section=.note --remove-section=.comment
-@@ -273,30 +273,32 @@ clean:
- 
- install-hotplug:
-   $(INSTALL) -d $(DESTDIR)$(hotplugdir)
--  $(INSTALL_PROGRAM) -D hotplug/pcmcia.agent 
$(DESTDIR)$(hotplugdir)/pcmcia.agent
--  $(INSTALL_PROGRAM) -D hotplug/pcmcia.rc 
$(DESTDIR)$(hotplugdir)/pcmcia.rc
-+  $(INSTALL_PROGRAM) hotplug/pcmcia.agent 
$(DESTDIR)$(hotplugdir)/pcmcia.agent
-+  $(INSTALL_PROGRAM) hotplug/pcmcia.rc $(DESTDIR)$(hotplugdir)/pcmcia.rc
- 
- uninstall-hotplug:
-   - rm -f $(DESTDIR)$(hotplugdir)/pcmcia.agent 
$(DESTDIR)$(hotplugdir)/pcmcia.rc
- 
- install-socket-hotplug:
--  $(INSTALL_PROGRAM) -D hotplug/pcmcia_socket.agent 
$(DESTDIR)$(hotplugdir)/pcmcia_socket.agent
--  $(INSTALL_PROGRAM) -D hotplug/pcmcia_socket.rc 
$(DESTDIR)$(hotplugdir)/pcmcia_socket.rc
-+  $(INSTALL_PROGRAM) hotplug/pcmcia_socket.agent 
$(DESTDIR)$(hotplugdir)/pcmcia_socket.agent
-+  $(INSTALL_PROGRAM) hotplug/pcmcia_socket.rc 
$(DESTDIR)$(hotplugdir)/pcmcia_socket.rc
- 
- uninstall-socket-hotplug:
-   - rm -f $(DESTDIR)$(hotplugdir)/pcmcia_socket.agent 
$(DESTDIR)$(hotplugdir)/pcmcia_socket.rc
- 
- install-socket-tools:
--  $(INSTALL_PROGRAM) -D $(PCMCIA_SOCKET_STARTUP) 
$(DESTDIR)$(udevhelperdir)/$(PCMCIA_SOCKET_STARTUP)
-+  $(INSTALL) -d $(DESTDIR)$(udevhelperdir)
-+  $(INSTALL_PROGRAM) $(PCMCIA_SOCKET_STARTUP) 
$(DESTDIR)$(udevhelperdir)/$(PCMCIA_SOCKET_STARTUP)
- 
- uninstall-socket-tools:
-   - rm -f $(DESTDIR)$(udevhelperdir)/$(PCMCIA_SOCKET_STARTUP)
- 
- install-tools:
-   $(INSTALL) -d $(DESTDIR)$(sbindir)
--  $(INSTALL_PROGRAM) -D $(PCCARDCTL) $(DESTDIR)$(sbindir)/$(PCCARDCTL)
-+  $(INSTALL) -d $(DESTDIR)$(udevhelperdir)
-+  $(INSTALL_PROGRAM) $(PCCARDCTL) $(DESTDIR)$(sbindir)/$(PCCARDCTL)
-   $(SYMLINK) $(PCCARDCTL) $(DESTDIR)$(sbindir)/$(LSPCMCIA)
--  $(INSTALL_PROGRAM) -D $(PCMCIA_CHECK_BROKEN_CIS) 
$(DESTDIR)$(udevhelperdir)/$(PCMCIA_CHECK_BROKEN_CIS)
-+

[OE-core] [PATCH] tune-xscale.inc: restore specific tuning

2018-08-14 Thread Andrea Adami

Since commit

 a11bdc36a1be
 tune-*: define more generic DEFAULTTUNE to share feed between machines

we are using armv5te to share binary feeds.

After 008085450417 gcc-8: Fix spurious mcpu/march conflict for xscale
we can use again the specific optimizations.

As of today, there are no public feeds for the legacy devices so let's prefer
the optimal tuning.

Signed-off-by: Andrea Adami 
---
 meta/conf/machine/include/tune-xscale.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/tune-xscale.inc 
b/meta/conf/machine/include/tune-xscale.inc
index 0d07333..cd08b93 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv5te"
+DEFAULTTUNE ?= "xscale"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
 
-- 
2.7.4

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

Re: [OE-core] [PATCH] tune-xscale.inc: restore specific tuning

2018-08-14 Thread Richard Purdie

On Tue, 2018-08-14 at 16:10 +0200, Andrea Adami wrote:
> Since commit
> 
>  a11bdc36a1be
>  tune-*: define more generic DEFAULTTUNE to share feed between
> machines
> 
> we are using armv5te to share binary feeds.
> 
> After 008085450417 gcc-8: Fix spurious mcpu/march conflict for xscale
> we can use again the specific optimizations.
> 
> As of today, there are no public feeds for the legacy devices so
> let's prefer
> the optimal tuning.
> 
> Signed-off-by: Andrea Adami 
> ---
>  meta/conf/machine/include/tune-xscale.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/conf/machine/include/tune-xscale.inc
> b/meta/conf/machine/include/tune-xscale.inc
> index 0d07333..cd08b93 100644
> --- a/meta/conf/machine/include/tune-xscale.inc
> +++ b/meta/conf/machine/include/tune-xscale.inc
> @@ -1,4 +1,4 @@
> -DEFAULTTUNE ?= "armv5te"
> +DEFAULTTUNE ?= "xscale"

Does this make any real world difference except for duplicating feeds?

Cheers,

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

[OE-core] [PATCH v4] runqemu: exit gracefully with an error message if qemu system is not evaluated

2018-08-14 Thread Jagadeesh Krishnanjanappa

It solves below error:
-- snip --
return 'qemu-system-%s' % qbsys
UnboundLocalError: local variable 'qbsys' referenced before assignment
-- snip --

[YOCTO #12846]

Signed-off-by: Jagadeesh Krishnanjanappa 
---
 scripts/runqemu | 5 +
 1 file changed, 5 insertions(+)

diff --git a/scripts/runqemu b/scripts/runqemu
index f52b9a8..409d17c 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1118,6 +1118,11 @@ class BaseConfig(object):
 qbsys = 'riscv64'
 elif mach == 'qemuriscv32':
 qbsys = 'riscv32'
+else:
+logger.error("Unable to determine QEMU PC System emulator for %s 
machine." % mach)
+logger.error("As %s is not among valid QEMU machines such as," % 
mach)
+logger.error("qemux86-64, qemux86, qemuarm64, qemuarm, qemumips64, 
qemumips64el, qemumipsel, qemumips, qemuppc")
+raise RunQemuError("Set qb_system_name with suitable QEMU PC 
System emulator in .*qemuboot.conf.")
 
 return 'qemu-system-%s' % qbsys
 
-- 
1.8.3.1

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

[OE-core] [oe][meta-qt5]: required packages to run qt5 qml applications

2018-08-14 Thread Mohamed Dawod

Hi,
I need to know what is the minimum packages which I need to add to
IMAGE_INSTALL_append variable in local.conf file
to be able to run qt5 qml applications in custom image on Minnowboard
Turbot that support wayland without x11. ?

Thank you,


-- 

Mohamed Dawod
Computer Engineering Department
Faculty of Engineering
Cairo University
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Yocto Project Status WW33’18

2018-08-14 Thread Jolley, Stephen K

Current Dev Position: YP 2.6 M3.

Next Deadline: YP 2.6 M3 Build Target is Aug. 27, 2018


SWAT Team Rotation:

· SWAT lead is currently: Maxin

· SWAT team rotation: Maxin -> Chen on Aug. 17, 2018

· SWAT team rotation: Chen -> Paul on Aug. 24, 2018

· https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

· YP 2.6 M2 released on 8/10/18.

· YP 2.5.1 is in QA. See 
https://wiki.yoctoproject.org/wiki/2.5_QA_Status.  It is 98% complete and 
should finish soon.

· A summary of sstate usage was added to the initial build output which 
gives numbers for the fraction of artefacts which are being reused. We may need 
to tweak the presentation to the user but its good information to provide and 
feedback on it is welcome.

· Glibc 2.28 is proving to have a number of issues to integrate 
including the significant size increase of its locale data, creating locale 
archives is likely the way forward for images reducing their size in 
core-image-lsb-sdk from ~900MB to ~220MB. The patches remain -next whilst fixes 
for issues are confirmed.

· Many other miscellaneous fixes were merged covering many aspects of 
the system.

· A potential DoS style issue was found in the bitbake checksum code 
and in fixing it the improvement of the checksumming code measurably improved 
(Thanks Ross!)

· The sstate equivalency server work from Joshua/Garmin has review 
still pending but the related persist_data improvements are queued for merging.

· The kernel-devsrc rework from Bruce/Windriver is pending patch 
resubmission.

· 2.4 (rocko) series stabilization continues for the next point release 
2.4.4


Planned Releases for YP 2.6:

· YP 2.6 M3 Build Target is Aug. 27, 2018

· YP 2.6 M3 Release Target is Sept. 7, 2018

· YP 2.6 M4 Build Target is Oct. 1, 2018

· YP 2.6 M4 Release Target is Oct. 26, 2018


Planned upcoming dot releases:

· YP 2.5.1 (Sumo) is in QA.

· YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done.

· YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done.


Tracking Metrics:

· WDD 2592 (last week 2590) 
(https://wiki.yoctoproject.org/charts/combo.html)

· Poky Patch Metrics

oTotal patches found: 1616 (last week 1608)

oPercentage of patches in the Pending State: 736 (46%) [last week 730 (45%)]


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:(208) 244-4460
• Email: stephen.k.jol...@intel.com

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

[OE-core] [rocko][PATCH] multilib_header: recognize BPF as a target

2018-08-14 Thread Daniel Díaz

When building with `clang -target bpf` using the
multilib_header, a recursion was unavoidable because
bits/wordsize.h would #include itself, still lacking
a definition for __MHWORDSIZE or __WORDSIZE.

(From OE-Core rev: 70b41b3c335a80b4ac243f468f22331d261299db)

Signed-off-by: Daniel Díaz 
Signed-off-by: Richard Purdie 
---
 scripts/multilib_header_wrapper.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/multilib_header_wrapper.h 
b/scripts/multilib_header_wrapper.h
index f516673..9660225 100644
--- a/scripts/multilib_header_wrapper.h
+++ b/scripts/multilib_header_wrapper.h
@@ -22,7 +22,9 @@
  */
 
 
-#if defined (__arm__)
+#if defined (__bpf__)
+#define __MHWORDSIZE   64
+#elif defined (__arm__)
 #define __MHWORDSIZE   32
 #elif defined (__aarch64__) && defined ( __LP64__)
 #define __MHWORDSIZE   64
-- 
2.7.4

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

[OE-core] [sumo][PATCH 1/2] glibc: Make bits/wordsize.h multilibbed again

2018-08-14 Thread Daniel Díaz

As reported by ChenQi, leaving bits/wordsize.h out of being
multilibbed introduced a problem in building the SDK for
arm64:
  Error: Transaction check error:
file /usr/include/bits/wordsize.h conflicts between attempted installs of 
lib32-libc6-dev-2.27-r0.armv7vet2hf_vfp and libc6-dev-2.27-r0.aarch64

This effectively reverts commit a74c77d6.

(From OE-Core rev: 90ad502bf8faa233e25cf297c1eeefcb0367aea3)

Signed-off-by: Daniel Díaz 
Signed-off-by: Richard Purdie 
---
 meta/recipes-core/glibc/glibc-package.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 35f5231..c1d186a 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -137,7 +137,7 @@ do_install_append_armeb () {
 }
 
 do_install_armmultilib () {
-   oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h 
bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h
+   oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h 
bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h bits/wordsize.h
oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h 
bits/pthreadtypes.h bits/pthreadtypes-arch.h  bits/sem.h  bits/semaphore.h 
bits/setjmp.h
oe_multilib_header bits/shm.h bits/sigstack.h bits/stat.h bits/statfs.h 
bits/typesizes.h
 
-- 
2.7.4

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

[OE-core] [sumo][PATCH 2/2] multilib_header: recognize BPF as a target

2018-08-14 Thread Daniel Díaz

When building with `clang -target bpf` using the
multilib_header, a recursion was unavoidable because
bits/wordsize.h would #include itself, still lacking
a definition for __MHWORDSIZE or __WORDSIZE.

(From OE-Core rev: 70b41b3c335a80b4ac243f468f22331d261299db)

Signed-off-by: Daniel Díaz 
Signed-off-by: Richard Purdie 
---
 scripts/multilib_header_wrapper.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/multilib_header_wrapper.h 
b/scripts/multilib_header_wrapper.h
index f516673..9660225 100644
--- a/scripts/multilib_header_wrapper.h
+++ b/scripts/multilib_header_wrapper.h
@@ -22,7 +22,9 @@
  */
 
 
-#if defined (__arm__)
+#if defined (__bpf__)
+#define __MHWORDSIZE   64
+#elif defined (__arm__)
 #define __MHWORDSIZE   32
 #elif defined (__aarch64__) && defined ( __LP64__)
 #define __MHWORDSIZE   64
-- 
2.7.4

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

[OE-core] [PATCH] oe-pkgdata-util: improve resiliance of lookup-recipe

2018-08-14 Thread Ross Burton

If we can't find the pkgdata for a package, instead of erroring out just emit a
message and continue.

This makes it possible to pass long lists of packages to oe-pkgdata-util and
process the output.

Signed-off-by: Ross Burton 
---
 scripts/oe-pkgdata-util | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/oe-pkgdata-util b/scripts/oe-pkgdata-util
index e6c9df94e83..5d2e328ee08 100755
--- a/scripts/oe-pkgdata-util
+++ b/scripts/oe-pkgdata-util
@@ -279,10 +279,10 @@ def lookup_recipe(args):
 parse_pkgdatafile(pkgdatafile)
 continue
 pkgdatafile = os.path.join(args.pkgdata_dir, 'runtime-reverse', pkg)
-if not os.path.exists(pkgdatafile):
-logger.error("The following packages could not be found: %s" % pkg)
-sys.exit(1)
-parse_pkgdatafile(pkgdatafile)
+if os.path.exists(pkgdatafile):
+parse_pkgdatafile(pkgdatafile)
+else:
+print("The following packages could not be found: %s" % pkg)
 
 def package_info(args):
 def parse_pkgdatafile(pkgdatafile):
-- 
2.11.0

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

Re: [OE-core] [oe][meta-qt5]: required packages to run qt5 qml applications

2018-08-14 Thread Khem Raj

you need to add meta-qt5 to your bblayers.conf and then
something like below might be helpful. You have to check for
renames or removals though.

IMAGE_INSTALL_append = "\
   qtbase-fonts \
   qtbase-plugins \
   qtbase-tools \
   qtbase-examples \
   qtdeclarative \
   qtdeclarative-plugins \
   qtdeclarative-tools \
   qtdeclarative-examples \
   qtdeclarative-qmlplugins \
   qtmultimedia \
   qtmultimedia-plugins \
   qtmultimedia-examples \
   qtmultimedia-qmlplugins \
   qtsvg \
   qtsvg-plugins \
   qtsensors \
   qtimageformats-plugins \
   qtsystems \
   qtsystems-tools \
   qtsystems-examples \
   qtsystems-qmlplugins \
   qtscript \
   qt3d \
   qt3d-examples \
   qt3d-qmlplugins \
   qt3d-tools \
   qtwebkit \
   qtwebkit-examples \
   qtwebkit-qmlplugins \
   qtgraphicaleffects-qmlplugins \
   qtconnectivity-qmlplugins \
   qtlocation-plugins \
   qtlocation-qmlplugins \
   cinematicexperience \
"
On Tue, Aug 14, 2018 at 7:41 AM Mohamed Dawod  wrote:
>
> Hi,
> I need to know what is the minimum packages which I need to add to
> IMAGE_INSTALL_append variable in local.conf file
> to be able to run qt5 qml applications in custom image on Minnowboard Turbot 
> that support wayland without x11. ?
>
> Thank you,
>
>
> --
>
> Mohamed Dawod
> Computer Engineering Department
> Faculty of Engineering
> Cairo University
> --
> ___
> 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] iotop: failure, python module subprocess is missing

2018-08-14 Thread Isaac Nickaein

Hi,

iotop built in my custom image complains about missing subprocess module:

   root@colibri-imx7-emmc:~# iotop
   No module named subprocess
   To run an uninstalled copy of iotop,
   launch iotop.py in the top directory
   root@colibri-imx7-emmc:~#

Shouldn't the iotop RDEPENDS on python-subprocess?

I'm on rocko 2.4.2 with following recipe for iotop:
http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/iotop/iotop_0.6.bb?h=rocko
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] iotop: failure, python module subprocess is missing

2018-08-14 Thread Burton, Ross

Yes.  Should be a simple fix. :)

On 14 August 2018 at 17:27, Isaac Nickaein  wrote:
> Hi,
>
> iotop built in my custom image complains about missing subprocess module:
>
>root@colibri-imx7-emmc:~# iotop
>No module named subprocess
>To run an uninstalled copy of iotop,
>launch iotop.py in the top directory
>root@colibri-imx7-emmc:~#
>
> Shouldn't the iotop RDEPENDS on python-subprocess?
>
> I'm on rocko 2.4.2 with following recipe for iotop:
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/iotop/iotop_0.6.bb?h=rocko
> --
> ___
> 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 V4 1/2] musl: Fix dirent struct alignment issue seen on armv5te

2018-08-14 Thread Khem Raj

- its a general problem however observed on armv5te based boards in OE
  other arches either have ways to compensate for misaligned access in hardware
  or compiler does not use 8byte alignment

- fix internal linux headers

Full logs
https://git.musl-libc.org/cgit/musl/log/?qt=range&q=9cad27a3dc1a4eb349b6591e4dc8cc89dce32277..1ad8138819ced49851e618c9c063aa0ffc86718c

Signed-off-by: Khem Raj 
---
v4:
Update to latest upstream master

 meta/recipes-core/musl/musl_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/musl/musl_git.bb 
b/meta/recipes-core/musl/musl_git.bb
index b56870cb3f..c13371014a 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -3,7 +3,7 @@
 
 require musl.inc
 
-SRCREV = "9cad27a3dc1a4eb349b6591e4dc8cc89dce32277"
+SRCREV = "1ad8138819ced49851e618c9c063aa0ffc86718c"
 
 PV = "1.1.19+git${SRCPV}"
 
-- 
2.18.0

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

[OE-core] [PATCH 2/2] eglinfo: Fix build with raspberrypi with userland graphics driver

2018-08-14 Thread Khem Raj

Let pkgconfig figure out headers and libraries instead of manually
forcing waf to do it.

Signed-off-by: Khem Raj 
---
 meta/recipes-graphics/eglinfo/eglinfo.inc |  3 +-
 ...01-Check-for-libegl-using-pkg-config.patch | 31 +++
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-graphics/eglinfo/files/0001-Check-for-libegl-using-pkg-config.patch

diff --git a/meta/recipes-graphics/eglinfo/eglinfo.inc 
b/meta/recipes-graphics/eglinfo/eglinfo.inc
index 8e7d9bddda..c8f0e897bf 100644
--- a/meta/recipes-graphics/eglinfo/eglinfo.inc
+++ b/meta/recipes-graphics/eglinfo/eglinfo.inc
@@ -8,6 +8,7 @@ DEPENDS = "virtual/egl"
 
 SRC_URI = "git://github.com/dv1/eglinfo.git;branch=master \
file://0001-Add-STAGING_INCDIR-to-searchpath-for-egl-headers.patch \
+   file://0001-Check-for-libegl-using-pkg-config.patch \
   "
 SRCREV = "4b317648ec6cf39556a9e5d8078f605bc0edd5de"
 
@@ -15,7 +16,7 @@ CVE_PRODUCT = "eglinfo"
 
 S = "${WORKDIR}/git"
 
-inherit waf distro_features_check
+inherit waf distro_features_check pkgconfig
 # depends on virtual/egl
 REQUIRED_DISTRO_FEATURES ?= "opengl"
 
diff --git 
a/meta/recipes-graphics/eglinfo/files/0001-Check-for-libegl-using-pkg-config.patch
 
b/meta/recipes-graphics/eglinfo/files/0001-Check-for-libegl-using-pkg-config.patch
new file mode 100644
index 00..0289ac228c
--- /dev/null
+++ 
b/meta/recipes-graphics/eglinfo/files/0001-Check-for-libegl-using-pkg-config.patch
@@ -0,0 +1,31 @@
+From 58d51d941d3f4dfa38be18282d3e285d76d9020d Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Mon, 13 Aug 2018 15:46:53 -0700
+Subject: [PATCH] Check for libegl using pkg-config
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+---
+ wscript | 1 +
+ 1 file changed, 1 insertion(+)
+
+Index: git/wscript
+===
+--- git.orig/wscript
 git/wscript
+@@ -160,14 +160,9 @@ def configure_raspberrypi_device(conf, p
+   conf.env['PLATFORM_USELIBS'] += ["X11"]
+   elif platform == "fb":
+   conf.env['PLATFORM_SOURCE'] = 
['src/platform_fb_raspberrypi.cpp']
+-  conf.check_cxx(mandatory = 1, lib = ['GLESv2', 'EGL', 'bcm_host'], 
uselib_store = 'EGL')
++  conf.check_cfg(package='egl', args='--libs --cflags')
+   import os
+   sysroot = conf.options.sysroot + conf.options.prefix
+-std_include_path = os.path.join(sysroot, 'include')
+-  vcos_pthread_path = os.path.join(sysroot, 
'include/interface/vcos/pthreads')
+-  vcms_host_path = os.path.join(sysroot, 
'include/interface/vmcs_host/linux')
+-  if not conf.check_cxx(mandatory = 0, header_name = 
['vcos_platform_types.h', 'EGL/egl.h', 'bcm_host.h'], includes = 
[vcos_pthread_path, vcms_host_path, std_include_path], uselib_store = 'EGL'):
+-  conf.fatal('Check if --prefix and --sysroot are set correctly.')
+   conf.env['WITH_APIS'] = []
+   if check_gles2(conf):
+   conf.env['WITH_APIS'] += ['GLES1', 'GLES2']
-- 
2.18.0

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

Re: [OE-core] [PATCH 2/2] libxml-parser-perl: fix "...contains bad RPATH"

2018-08-14 Thread Jens Rehsack

Hi Richard,

I tried:

$ bitbake libxml-parser-perl-native nativesdk-libxml-parser-perl 
libxml-parser-perl

WARNING: Host distribution "ubuntu-18.04" has not been validated with this 
version of the build system; you may possibly experience unexpected failures. 
It is recommended that you use a tested distribution.
Loading cache: 100% 
|##|
 Time: 0:00:00
Loaded 3693 entries from dependency cache.
Parsing recipes: 100% 
||
 Time: 0:00:01
Parsing of 2421 .bb files complete (2417 cached, 4 parsed). 3685 targets, 100 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.39.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "arm-poky-linux-gnueabi"
MACHINE  = "wendy"
DISTRO   = "gpw"
DISTRO_VERSION   = "1.0.0"
TUNE_FEATURES= "arm armv7a vfp neon callconvention-hard cortexa8"
TARGET_FPU   = "hard"
meta
meta-poky
meta-yocto-bsp   = "master:e82d2edca398c392309713577859724900b20190"
meta-oe
meta-python
meta-networking
meta-filesystems
meta-webserver   = "master:0691e134bf938e0712cf14d3a441bbba04727cea"
meta-cpan= "master:7ddb7aae38ad9c8fc850026de6636fbe2a4aabdd"
meta-jens= "master:92863f571a9b64aa5b6c6866db9eb0c8972a546f"
meta-gpw = "master:8679df6ae6a22b15bd4127c838915dcf087bf614"

Initialising tasks: 100% 
|#|
 Time: 0:00:00
Checking sstate mirror object availability: 100% 
|#|
 Time: 0:00:00
Sstate summary: Wanted 155 Found 0 Missed 310 Current 96 (0% match, 38% 
complete)
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 1007 tasks of which 669 didn't need to be rerun 
and all succeeded.

Unfortunately I don't have a SuSE based build machine nor a reasonable MIPS 
setup to test - but can you please describe what I need to do to reproduce that 
error?
Further: Ross complained regarding patch corruption by Apple Mail - I resent 
the patches on August, 8th (you replied that on August, 6th) using 
git-send-email. Did you fix the corrupted patch before?

I really want this thing being fixed - does it occurs anywhere else or can the 
reason the missing "--sysroot"?

When I restrict the additional sed commands to target only, how would that 
affect the nativesdk?

Cheers,
Jens

> Am 06.08.2018 um 17:22 schrieb richard.pur...@linuxfoundation.org:
> 
> On Thu, 2018-08-02 at 10:21 +0200, Jens Rehsack wrote:
>> The perl distribution "XML-Parser" relies for configuration
>> on the tooling of Devel::CheckLib - which is not aware of
>> sysroot locations nor of reasonable compiler/link definitions
>> from outside.
>> 
>> This causes
>> 
>>ERROR: libxml-parser-perl-2.44-r0 do_package_qa: QA Issue: package 
>> libxml-parser-perl contains bad RPATH 
>> ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/recipe-sysroot/usr/lib
>>  in file 
>> ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/packages-split/libxml-parser-perl/usr/lib/perl/vendor_perl/5.24.4/auto/XML/Parser/Expat/Expat.so
>>package libxml-parser-perl contains bad RPATH 
>> ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/recipe-sysroot/usr/lib
>>  in file 
>> ${BUILDDIR}/tmp/work/core2-64-poky-linux/libxml-parser-perl/2.44-r0/packages-split/libxml-parser-perl/usr/lib/perl/vendor_perl/5.24.4/auto/XML/Parser/Expat/Expat.so
>>  [rpaths]
>>ERROR: libxml-parser-perl-2.44-r0 do_package_qa: QA run found fatal 
>> errors. Please consider fixing them.
>>ERROR: libxml-parser-perl-2.44-r0 do_package_qa: Function failed: 
>> do_package_qa
>> 
>> It's strongly encouraged to the maintainer @toddr to rework the
>> toolchain for up to date environments.
>> 
>> Signed-off-by: Jens Rehsack 
>> ---
>> meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb 
>> b/meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb
>> index c5e0ae6769..2ca8d506f4 100644
>> --- a/meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb
>> +++ b/meta/recipes-devtools/perl/libxml-parser-perl_2.44.bb
>> @@ -19,7 +19,11 @@ inherit cpan ptest-perl
>> # fix up sub MakeMaker project as arguments don't get propagated though
>> # see https://rt.cpan.o

Re: [OE-core] [PATCH] tune-xscale.inc: restore specific tuning

2018-08-14 Thread Khem Raj

On Tue, Aug 14, 2018 at 7:24 AM Richard Purdie
 wrote:
>
> On Tue, 2018-08-14 at 16:10 +0200, Andrea Adami wrote:
> > Since commit
> >
> >  a11bdc36a1be
> >  tune-*: define more generic DEFAULTTUNE to share feed between
> > machines
> >
> > we are using armv5te to share binary feeds.
> >
> > After 008085450417 gcc-8: Fix spurious mcpu/march conflict for xscale
> > we can use again the specific optimizations.
> >
> > As of today, there are no public feeds for the legacy devices so
> > let's prefer
> > the optimal tuning.
> >
> > Signed-off-by: Andrea Adami 
> > ---
> >  meta/conf/machine/include/tune-xscale.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/machine/include/tune-xscale.inc
> > b/meta/conf/machine/include/tune-xscale.inc
> > index 0d07333..cd08b93 100644
> > --- a/meta/conf/machine/include/tune-xscale.inc
> > +++ b/meta/conf/machine/include/tune-xscale.inc
> > @@ -1,4 +1,4 @@
> > -DEFAULTTUNE ?= "armv5te"
> > +DEFAULTTUNE ?= "xscale"
>
> Does this make any real world difference except for duplicating feeds?

Usually it should, since compiler should be able to use
xscale specific instructions during codegen  , it will be interesting
to see numbers to measure the gain.

>
> Cheers,
>
> Richard
> --
> ___
> 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/6] package_manager: Remove rpm specific pieces of create_packages_dir()

2018-08-14 Thread Richard Purdie

This function is generic, tweak the variable names and move out the rpm specific
directory name to make it truly generic and reusable for deb/ipk.

Signed-off-by: Richard Purdie 
---
 meta/lib/oe/package_manager.py | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 6011e873503..f1dbe48a720 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -621,7 +621,7 @@ class PackageManager(object, metaclass=ABCMeta):
 return res
 return _append(uris, base_paths)
 
-def create_packages_dir(d, rpm_repo_dir, deploydir, taskname, 
filterbydependencies):
+def create_packages_dir(d, subrepo_dir, deploydir, taskname, 
filterbydependencies):
 """
 Go through our do_package_write_X dependencies and hardlink the packages 
we depend
 upon into the repo directory. This prevents us seeing other packages that 
may
@@ -636,15 +636,13 @@ def create_packages_dir(d, rpm_repo_dir, deploydir, 
taskname, filterbydependenci
 seendirs = set()
 multilibs = {}

-rpm_subrepo_dir = oe.path.join(rpm_repo_dir, "rpm")
-
-bb.utils.remove(rpm_subrepo_dir, recurse=True)
-bb.utils.mkdirhier(rpm_subrepo_dir)
+bb.utils.remove(subrepo_dir, recurse=True)
+bb.utils.mkdirhier(subrepo_dir)
 
 # Detect bitbake -b usage
 nodeps = d.getVar("BB_LIMITEDDEPS") or False
 if nodeps or not filterbydependencies:
-oe.path.symlink(deploydir, rpm_subrepo_dir, True)
+oe.path.symlink(deploydir, subrepo_dir, True)
 return
 
 start = None
@@ -655,24 +653,24 @@ def create_packages_dir(d, rpm_repo_dir, deploydir, 
taskname, filterbydependenci
 break
 if start is None:
 bb.fatal("Couldn't find ourself in BB_TASKDEPDATA?")
-rpmdeps = set()
+pkgdeps = set()
 start = [start]
 seen = set(start)
-# Support direct dependencies (do_rootfs -> rpms)
-# or indirect dependencies within PN (do_populate_sdk_ext -> do_rootfs -> 
rpms)
+# Support direct dependencies (do_rootfs -> do_package_write_X)
+# or indirect dependencies within PN (do_populate_sdk_ext -> do_rootfs -> 
do_package_write_X)
 while start:
 next = []
 for dep2 in start:
 for dep in taskdepdata[dep2][3]:
 if taskdepdata[dep][0] != pn:
 if "do_" + taskname in dep:
-rpmdeps.add(dep)
+pkgdeps.add(dep)
 elif dep not in seen:
 next.append(dep)
 seen.add(dep)
 start = next
 
-for dep in rpmdeps:
+for dep in pkgdeps:
 c = taskdepdata[dep][0]
 manifest, d2 = oe.sstatesig.find_sstate_manifest(c, 
taskdepdata[dep][2], taskname, d, multilibs)
 if not manifest:
@@ -683,7 +681,7 @@ def create_packages_dir(d, rpm_repo_dir, deploydir, 
taskname, filterbydependenci
 for l in f:
 l = l.strip()
 dest = l.replace(deploydir, "")
-dest = rpm_subrepo_dir + dest
+dest = subrepo_dir + dest
 if l.endswith("/"):
 if dest not in seendirs:
 bb.utils.mkdirhier(dest)
@@ -725,7 +723,7 @@ class RpmPM(PackageManager):
 self.primary_arch = self.d.getVar('MACHINE_ARCH')
 
 self.rpm_repo_dir = oe.path.join(self.d.getVar('WORKDIR'), 
rpm_repo_workdir)
-create_packages_dir(self.d, self.rpm_repo_dir, 
d.getVar("DEPLOY_DIR_RPM"), "package_write_rpm", filterbydependencies)
+create_packages_dir(self.d, oe.path.join(self.rpm_repo_dir, "rpm"), 
d.getVar("DEPLOY_DIR_RPM"), "package_write_rpm", filterbydependencies)
 
 self.saved_packaging_data = 
self.d.expand('${T}/saved_packaging_data/%s' % self.task_name)
 if not os.path.exists(self.d.expand('${T}/saved_packaging_data')):
-- 
2.17.1

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

[OE-core] [PATCH 3/6] sstate: Ensure a given machine only removes things which it created

2018-08-14 Thread Richard Purdie

Currently if you build qemux86 and then generic86, the latter will
remove all of the former from deploy and workdir. This is because
qemux86 is i586, genericx86 is i686 and the architctures are compatible
therefore the sstate 'cleaup' code kicks in.

There was a valid reason for this to ensure i586 packages didn't get into
an i686 rootfs for example. With the rootfs creation being filtered now, this
is no longer necessary.

Instead, save out a list of stamps which a give machine has ever seen in
a given build and only clean up these things if they're no longer
"reachable".

In particular this means the autobuilder should no longer spend a load of time
deleting files when switching MACHINE, improving build times.

Signed-off-by: Richard Purdie 
---
 meta/classes/sstate.bbclass | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 9927c76596e..a091c6e843e 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -1045,6 +1045,15 @@ python sstate_eventhandler2() {
 with open(preservestampfile, 'r') as f:
 preservestamps = f.readlines()
 seen = []
+
+# The machine index contains all the stamps this machine has ever seen in 
this build directory.
+# We should only remove things which this machine once accessed but no 
longer does.
+machineindex = set()
+mi = d.expand("${SSTATE_MANIFESTS}/index-machine-${MACHINE}")
+if os.path.exists(mi):
+with open(mi, "r") as f:
+machineindex = set(f.readlines())
+
 for a in sorted(list(set(d.getVar("SSTATE_ARCHS").split(:
 toremove = []
 i = d.expand("${SSTATE_MANIFESTS}/index-" + a)
@@ -1054,7 +1063,7 @@ python sstate_eventhandler2() {
 lines = f.readlines()
 for l in lines:
 (stamp, manifest, workdir) = l.split()
-if stamp not in stamps and stamp not in preservestamps:
+if stamp not in stamps and stamp not in preservestamps and 
stamp in machineindex:
 toremove.append(l)
 if stamp not in seen:
 bb.debug(2, "Stamp %s is not reachable, removing 
related manifests" % stamp)
@@ -1083,6 +1092,11 @@ python sstate_eventhandler2() {
 with open(i, "w") as f:
 for l in lines:
 f.write(l)
+machineindex |= set(stamps)
+with open(mi, "w") as f:
+for l in machineindex:
+f.write(l + "\n")
+
 if preservestamps:
 os.remove(preservestampfile)
 }
-- 
2.17.1

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

[OE-core] [PATCH 4/6] selftest: Replace bitbake -p with bitbake -e

2018-08-14 Thread Richard Purdie

Parsing all the recipes is annoying when trying to re-execute oe-selftest
and also unnecessary as its really just a sanity check. When the tests were
originally being developed the guard was useful but less so now.

Replace it with bitbake -e which is fast and checks the basic configuration
is valid.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/context.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/selftest/context.py 
b/meta/lib/oeqa/selftest/context.py
index 3a70f9e77b0..c78947e200b 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -201,8 +201,8 @@ class OESelftestTestContextExecutor(OETestContextExecutor):
 
 _add_layer_libs()
 
-self.tc.logger.info("Running bitbake -p")
-runCmd("bitbake -p")
+self.tc.logger.info("Running bitbake -e to test the configuration is 
valid/parsable")
+runCmd("bitbake -e")
 
 def _internal_run(self, logger, args):
 self.module_paths = self._get_cases_paths(
-- 
2.17.1

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

[OE-core] [PATCH 5/6] sstate/lib.oe.path: Ensure file sparseness is preserved

2018-08-14 Thread Richard Purdie

Files when restored from sstate were missing their sparseness. Fix up various
functions to preserve this and make things more deterministic.

Signed-off-by: Richard Purdie 
---
 meta/classes/sstate.bbclass | 4 ++--
 meta/lib/oe/path.py | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index a091c6e843e..1c166ff6745 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -721,9 +721,9 @@ sstate_create_package () {
TFILE=`mktemp ${SSTATE_PKG}.`
 
 # Use pigz if available
-OPT="-cz"
+OPT="-czS"
 if [ -x "$(command -v pigz)" ]; then
-OPT="-I pigz -c"
+OPT="-I pigz -cS"
 fi
 
# Need to handle empty directories
diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py
index be02218c31d..1e24d0586b6 100644
--- a/meta/lib/oe/path.py
+++ b/meta/lib/oe/path.py
@@ -86,7 +86,7 @@ def copytree(src, dst):
 # This way we also preserve hardlinks between files in the tree.
 
 bb.utils.mkdirhier(dst)
-cmd = "tar --xattrs --xattrs-include='*' -cf - -C %s -p . | tar --xattrs 
--xattrs-include='*' -xf - -C %s" % (src, dst)
+cmd = "tar --xattrs --xattrs-include='*' -cf - -S -C %s -p . | tar 
--xattrs --xattrs-include='*' -xf - -C %s" % (src, dst)
 subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
 
 def copyhardlinktree(src, dst):
@@ -98,7 +98,7 @@ def copyhardlinktree(src, dst):
 if (os.stat(src).st_dev ==  os.stat(dst).st_dev):
 # Need to copy directories only with tar first since cp will error if 
two 
 # writers try and create a directory at the same time
-cmd = "cd %s; find . -type d -print | tar --xattrs 
--xattrs-include='*' -cf - -C %s -p --no-recursion --files-from - | tar 
--xattrs --xattrs-include='*' -xhf - -C %s" % (src, src, dst)
+cmd = "cd %s; find . -type d -print | tar --xattrs 
--xattrs-include='*' -cf - -S -C %s -p --no-recursion --files-from - | tar 
--xattrs --xattrs-include='*' -xhf - -C %s" % (src, src, dst)
 subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
 source = ''
 if os.path.isdir(src):
-- 
2.17.1

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

[OE-core] [PATCH 2/6] package_manager/sdk: Use filtered copies of the deploy ipk/deb directories

2018-08-14 Thread Richard Purdie

Similar to rpm, use copies of the ipk/deb directories for rootfs construction.
This means the image creation code can no longer "see" recipes wich aren't in 
its
dependency chain which is good for a variety of reasons including determinism,
incompatible recipe (e.g. systemd/sysvinit) package conflicts and locking
performance.

Signed-off-by: Richard Purdie 
---
 meta/lib/oe/package_manager.py | 13 +
 meta/lib/oe/sdk.py | 20 
 meta/lib/oeqa/utils/package_manager.py |  6 --
 3 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index f1dbe48a720..0f1c5899fd5 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -1124,19 +1124,21 @@ class OpkgDpkgPM(PackageManager):
 self.mark_packages("unpacked", registered_pkgs.split())
 
 class OpkgPM(OpkgDpkgPM):
-def __init__(self, d, target_rootfs, config_file, archs, 
task_name='target'):
+def __init__(self, d, target_rootfs, config_file, archs, 
task_name='target', ipk_repo_workdir="oe-rootfs-repo", 
filterbydependencies=True):
 super(OpkgPM, self).__init__(d, target_rootfs)
 
 self.config_file = config_file
 self.pkg_archs = archs
 self.task_name = task_name
 
-self.deploy_dir = self.d.getVar("DEPLOY_DIR_IPK")
+self.deploy_dir = oe.path.join(self.d.getVar('WORKDIR'), 
ipk_repo_workdir)
 self.deploy_lock_file = os.path.join(self.deploy_dir, "deploy.lock")
 self.opkg_cmd = bb.utils.which(os.getenv('PATH'), "opkg")
 self.opkg_args = "--volatile-cache -f %s -t %s -o %s " % 
(self.config_file, self.d.expand('${T}/ipktemp/') ,target_rootfs)
 self.opkg_args += self.d.getVar("OPKG_ARGS")
 
+create_packages_dir(self.d, self.deploy_dir, 
d.getVar("DEPLOY_DIR_IPK"), "package_write_ipk", filterbydependencies)
+
 opkg_lib_dir = self.d.getVar('OPKGLIBDIR')
 if opkg_lib_dir[0] == "/":
 opkg_lib_dir = opkg_lib_dir[1:]
@@ -1501,9 +1503,12 @@ class OpkgPM(OpkgDpkgPM):
 return tmp_dir
 
 class DpkgPM(OpkgDpkgPM):
-def __init__(self, d, target_rootfs, archs, base_archs, apt_conf_dir=None):
+def __init__(self, d, target_rootfs, archs, base_archs, apt_conf_dir=None, 
deb_repo_workdir="oe-rootfs-repo", filterbydependencies=True):
 super(DpkgPM, self).__init__(d, target_rootfs)
-self.deploy_dir = self.d.getVar('DEPLOY_DIR_DEB')
+self.deploy_dir = oe.path.join(self.d.getVar('WORKDIR'), 
deb_repo_workdir)
+
+create_packages_dir(self.d, self.deploy_dir, 
d.getVar("DEPLOY_DIR_DEB"), "package_write_deb", filterbydependencies)
+
 if apt_conf_dir is None:
 self.apt_conf_dir = self.d.expand("${APTCONF_TARGET}/apt")
 else:
diff --git a/meta/lib/oe/sdk.py b/meta/lib/oe/sdk.py
index f20441ccf66..153b07d76b4 100644
--- a/meta/lib/oe/sdk.py
+++ b/meta/lib/oe/sdk.py
@@ -227,11 +227,17 @@ class OpkgSdk(Sdk):
 self.host_manifest = OpkgManifest(d, self.manifest_dir,
   Manifest.MANIFEST_TYPE_SDK_HOST)
 
+ipk_repo_workdir = "oe-sdk-repo"
+if "sdk_ext" in d.getVar("BB_RUNTASK"):
+ipk_repo_workdir = "oe-sdk-ext-repo"
+
 self.target_pm = OpkgPM(d, self.sdk_target_sysroot, self.target_conf,
-self.d.getVar("ALL_MULTILIB_PACKAGE_ARCHS"))
+self.d.getVar("ALL_MULTILIB_PACKAGE_ARCHS"), 
+ipk_repo_workdir=ipk_repo_workdir)
 
 self.host_pm = OpkgPM(d, self.sdk_host_sysroot, self.host_conf,
-  self.d.getVar("SDK_PACKAGE_ARCHS"))
+  self.d.getVar("SDK_PACKAGE_ARCHS"),
+ipk_repo_workdir=ipk_repo_workdir)
 
 def _populate_sysroot(self, pm, manifest):
 pkgs_to_install = manifest.parse_initial_manifest()
@@ -307,15 +313,21 @@ class DpkgSdk(Sdk):
 self.host_manifest = DpkgManifest(d, self.manifest_dir,
   Manifest.MANIFEST_TYPE_SDK_HOST)
 
+deb_repo_workdir = "oe-sdk-repo"
+if "sdk_ext" in d.getVar("BB_RUNTASK"):
+deb_repo_workdir = "oe-sdk-ext-repo"
+
 self.target_pm = DpkgPM(d, self.sdk_target_sysroot,
 self.d.getVar("PACKAGE_ARCHS"),
 self.d.getVar("DPKG_ARCH"),
-self.target_conf_dir)
+self.target_conf_dir,
+deb_repo_workdir=deb_repo_workdir)
 
 self.host_pm = DpkgPM(d, self.sdk_host_sysroot,
   self.d.getVar("SDK_PACKAGE_ARCHS"),
   self.d.getVar("DEB_SDK_ARCH"),
-  self.host_conf_dir)
+  self.host_conf_dir,
+

[OE-core] [PATCH 6/6] selftest/package: Improve test to cover sparseness and hardlinking from sstate

2018-08-14 Thread Richard Purdie

The sparseness test was sometimes working and sometimes failing depending
on whether sstate was valid. This adds an explict test of sstate
to the test for both hardlinking and sparseness. Tweak the test name to
cover the fact its tests sparseness too.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/cases/package.py | 27 -
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/package.py 
b/meta/lib/oeqa/selftest/cases/package.py
index 4ff9b08c96a..ee6430a1845 100644
--- a/meta/lib/oeqa/selftest/cases/package.py
+++ b/meta/lib/oeqa/selftest/cases/package.py
@@ -89,17 +89,26 @@ class VersionOrdering(OESelftestTestCase):
 class PackageTests(OESelftestTestCase):
 # Verify that a recipe which sets up hardlink files has those preserved 
into split packages
 # Also test file sparseness is preserved
-def test_preserve_hardlinks(self):
-result = bitbake("selftest-hardlink -c package")
+def test_preserve_sparse_hardlinks(self):
+bitbake("selftest-hardlink -c package")
 
 dest = get_bb_var('PKGDEST', 'selftest-hardlink')
 bindir = get_bb_var('bindir', 'selftest-hardlink')
 
-# Recipe creates 4 hardlinked files, there is a copy in package/ and a 
copy in packages-split/
-# so expect 8 in total.
-self.assertEqual(os.stat(dest + "/selftest-hardlink" + bindir + 
"/hello").st_nlink, 8)
+def checkfiles():
+# Recipe creates 4 hardlinked files, there is a copy in package/ 
and a copy in packages-split/
+# so expect 8 in total.
+self.assertEqual(os.stat(dest + "/selftest-hardlink" + bindir + 
"/hello").st_nlink, 8)
 
-# Test a sparse file remains sparse
-sparsestat = os.stat(dest + "/selftest-hardlink" + bindir + 
"/sparsetest")
-self.assertEqual(sparsestat.st_blocks, 0)
-self.assertEqual(sparsestat.st_size, 1048576)
+# Test a sparse file remains sparse
+sparsestat = os.stat(dest + "/selftest-hardlink" + bindir + 
"/sparsetest")
+self.assertEqual(sparsestat.st_blocks, 0)
+self.assertEqual(sparsestat.st_size, 1048576)
+
+checkfiles()
+
+# Clean and reinstall so its now definitely from sstate, then retest.
+bitbake("selftest-hardlink -c clean")
+bitbake("selftest-hardlink -c package")
+
+checkfiles()
-- 
2.17.1

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

Re: [OE-core] [oe-core][PATCH v3 2/2] runtime selftest: optimize the case of hw_breakpoint

2018-08-14 Thread Randy MacLeod

Subject:
   Re: [OE-core] [oe-core][PATCH v3 2/2] runtime selftest: optimize the 
case of hw_breakpoint

The subject/short log should be:
  runtime selftest: limit kernel hw bp arches

Hongzhi.Song wrote:
>
> 1. So far, only qemux86 can support hw breakpoint

When I first read this, I thought that you really meant only
qemux86 and NOT qemux86-64. Of course you mean: qemux86* so
please say so using '*' or qemux86[-64].

Does this work with and without the host using the kvm module?

> qemuppc: Runqemu uses G4 as the default cpu. But qemu doesn't simulate
> the hw breakpoint register for G4, which belong to 74xx series.

Okay. Please change the wording to something like:

qemuppc: The oe-core configuration uses a PPC G4 system as the
default cpu but qemu doesn't simulate the hw breakpoint register for G4.

>
> qemuarm: The arch more than v7 supports hw breakpoint, however arm use
> v5 as default.

What about qemuarm64 and qemumips* ?

I don't care about mips so much but it would be nice if
qemuarm64 had this emulation. Oh, the patch code also allows
testing aarch64 so I guess qemuarm64 works. Please mention
that in the log in your first sentence.

>
> 2. Rsyslog maybe not started, so we use dmesg to confirm.
s/Rsyslog/syslog/

There are several syslog implementations so just refer to the
generic function.

>
> 3. Adding the operation of 'ls' triggers hardware breakpoint.

s/Adding the operation of 'ls' triggers hardware breakpoint.
 /Run 'ls' to trigger the hardware breakpoint test.
 /

Please take the numbering out of your long log.

If you read through the oe-core commits, you'll see that
people rarely number each statement. Numbered lists can be
used in cases such as:
   5a7cf32967 openssl_1.0.2n: improve reproducibility

Almost done! :)
Other than the host kvm module question, and a clean-up
commit log, I think this is fine now.

I suspect that the glibc-2.28 upgrade is getting more attention
than this and other work so once the glibc upgrade is in master,
I'd hope that your V4 will be merged.

Thanks,

../Randy

Signed-off-by: Hongzhi.Song 
---
  meta/lib/oeqa/runtime/cases/ksample.py | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/lib/oeqa/runtime/cases/ksample.py 
b/meta/lib/oeqa/runtime/cases/ksample.py
index 26fbe9d8cb..eb8713351a 100644
--- a/meta/lib/oeqa/runtime/cases/ksample.py
+++ b/meta/lib/oeqa/runtime/cases/ksample.py
@@ -164,6 +164,11 @@ class KSampleTest(KSample):
  # hw breakpoint
  @OETestDepends(['ssh.SSHTest.test_ssh'])
  def test_hw_breakpoint_example(self):
+# check arch
+status, output = self.target.run("uname -m")
+result = ("x86" in output) or ("aarch64" in output)
+if not result:
+self.skipTest("the arch doesn't support hw breakpoint" % output)
  # check config
  self.check_config("CONFIG_KALLSYMS_ALL")
  # make sure if module exists

--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for "package_manager: Remove rpm sp..." and 5 more

2018-08-14 Thread Patchwork

== Series Details ==

Series: "package_manager: Remove rpm sp..." and 5 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/13512/
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 e2b8a3d5a1)



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] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
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] mesa: Disble TLS for musl

2018-08-14 Thread Khem Raj

See https://bugs.freedesktop.org/show_bug.cgi?id=35268
mesa should infact stop using __attribute__((tls_model("initial-exec")))
until then we disale TLS in glx for musl
The problem could happen even on glibc if static TLS sizes are large enough
which would mean that additional space the glibc leaves for such rogue libraries
get consumed and then same problems show up there as well

Fixes errors seen in xorg logs e.g.

(EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so: Error 
relocating /usr/lib/libGL.so.1: _ITM_deregisterTMCloneTable: initial-exec TLS 
resolves to dynamic definition in /usr/lib/libGL.so.1

enable readonly text segment on x86 for musl

Signed-off-by: Khem Raj 
---
 meta/recipes-graphics/mesa/mesa.inc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 860a2d94cc..3a723b59a6 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -105,11 +105,15 @@ PACKAGECONFIG[osmesa] = 
"--enable-${OSMESA},--disable-${OSMESA}"
 
 PACKAGECONFIG[unwind] = "--enable-libunwind,--disable-libunwind,libunwind"
 
+EXTRA_OECONF_remove_libc-musl = "--enable-glx-tls"
+EXTRA_OECONF_append_libc-musl = " --disable-glx-tls"
+
 # llvmpipe is slow if compiled with -fomit-frame-pointer (e.g. -O2)
 FULL_OPTIMIZATION_append = " -fno-omit-frame-pointer"
 
 CFLAGS_append_armv5 = " -DMISSING_64BIT_ATOMICS"
-
+CFLAGS_append_x86_libc-musl = " -DGLX_X86_READONLY_TEXT"
+CFLAGS_append_x86-64_libc-musl = " -DGLX_X86_READONLY_TEXT"
 EXTRA_OEMAKE += 
"WAYLAND_PROTOCOLS_DATADIR=${STAGING_DATADIR}/wayland-protocols"
 
 # Remove the mesa dependency on mesa-dev, as mesa is empty
-- 
2.18.0

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

Re: [OE-core] adding python modules

2018-08-14 Thread Alejandro Enedino Hernandez Samaniego


Hey Bhaskar, Alex


On 08/14/2018 01:18 AM, Alexander Kanavin wrote:

Simple - add python3-modules to the packagegroup. Sadly this seems to
be 'common knowledge' that is poorly documented.

Alex
I'm pretty sure that the python3-modules package is included by default 
when python is installed (on master)

if you wont be using master then yes, install python3-modules


2018-08-14 0:51 GMT+02:00 bhas_purk :

Hello,
I am new to yocto, and we are using this for an Intel SOC.
I am creating a console-image, and wanted to get python3 in the rootfs.

So I added python3 in the recipe file -
layers/meta-openembedded/meta-oe/recipes-core/packagegroups/packagegroup-basic.bb
This gave me python3 in the rootfs and I can run ptyhon3. So that is great!


Now I would like to add some modules to python such that they are built in,
and I dont have to do a pip install for the modules.

I see that there is a script file which generates the manifest for all
modules will be there.
openembedded-core/scripts/contrib/python/generate-manifest-3.5.py


I would like to edit this file to some python modules, and am wondering how.

For example, one of the existing modules in the script is defined like this-
   m.addPackage( "${PN}-argparse", "Python command line argument parser",
"${PN}-core ${PN}-codecs ${PN}-textutils",
 "argparse.*" )

The generate-manifest-3.5 script is no longer used (again, on master),
there is a new one called create-manifest where you can add more granularity
to the python build, but in this case I don't believe you need it.

Alejandro



So my question is, for the modules I would like to add, how do I know the
dependencies etc? And more importantly, is this the right way to add modules
to python3 in the rootfs.


Thank you
Bhaskar





--
___
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 V2] mesa: Disble TLS for musl

2018-08-14 Thread Khem Raj

See https://bugs.freedesktop.org/show_bug.cgi?id=35268
mesa should infact stop using __attribute__((tls_model("initial-exec")))
until then we disale TLS in glx for musl
The problem could happen even on glibc if static TLS sizes are large enough
which would mean that additional space the glibc leaves for such rogue libraries
get consumed and then same problems show up there as well

Fixes errors seen in xorg logs e.g.

(EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so: Error 
relocating /usr/lib/libGL.so.1: _ITM_deregisterTMCloneTable: initial-exec TLS 
resolves to dynamic definition in /usr/lib/libGL.so.1

enable readonly text segment on x86 for musl

Signed-off-by: Khem Raj 
---
V2: Use --enable-glx-read-only-text instead of setting CFLAGS

 meta/recipes-graphics/mesa/mesa.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 860a2d94cc..2671d4de4d 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -36,6 +36,7 @@ export LLVM_CONFIG = 
"${STAGING_BINDIR_NATIVE}/llvm-config${MESA_LLVM_RELEASE}"
 export YOCTO_ALTERNATE_EXE_PATH = 
"${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE}/llvm-config"
 EXTRA_OECONF = "--enable-shared-glapi \
 --disable-opencl \
+--enable-glx-read-only-text \
 PYTHON2=python2 \
 --with-llvm-prefix=${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE} \
 --with-platforms='${PLATFORMS}'"
@@ -105,11 +106,12 @@ PACKAGECONFIG[osmesa] = 
"--enable-${OSMESA},--disable-${OSMESA}"
 
 PACKAGECONFIG[unwind] = "--enable-libunwind,--disable-libunwind,libunwind"
 
+EXTRA_OECONF_remove_libc-musl = "--enable-glx-tls"
+EXTRA_OECONF_append_libc-musl = " --disable-glx-tls"
 # llvmpipe is slow if compiled with -fomit-frame-pointer (e.g. -O2)
 FULL_OPTIMIZATION_append = " -fno-omit-frame-pointer"
 
 CFLAGS_append_armv5 = " -DMISSING_64BIT_ATOMICS"
-
 EXTRA_OEMAKE += 
"WAYLAND_PROTOCOLS_DATADIR=${STAGING_DATADIR}/wayland-protocols"
 
 # Remove the mesa dependency on mesa-dev, as mesa is empty
-- 
2.18.0

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

[OE-core] [PATCHv2 1/2] meson: Split validate-cpu.patch in three

2018-08-14 Thread Peter Kjellerstedt

This makes it more suitable to work with, e.g., devtool. It also
prepares for the update to 0.47.0 when the first patch will no longer be
needed (as it is a backport).

Signed-off-by: Peter Kjellerstedt 
---
Patch v2: Rebased on current master due to conflicts.

 meta/recipes-devtools/meson/meson.inc  |  4 +-
 ...u.patch => 0001-Validate-cpu_family-3753.patch} | 80 ++
 .../0002-Make-CPU-family-warnings-fatal.patch  | 36 ++
 ...r-to-our-wiki-instead-of-Meson-bug-system.patch | 40 +++
 4 files changed, 115 insertions(+), 45 deletions(-)
 rename meta/recipes-devtools/meson/meson/{validate-cpu.patch => 
0001-Validate-cpu_family-3753.patch} (55%)
 create mode 100644 
meta/recipes-devtools/meson/meson/0002-Make-CPU-family-warnings-fatal.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0003-Send-user-to-our-wiki-instead-of-Meson-bug-system.patch

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
index a650469e93..c9e1e051c6 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -11,7 +11,9 @@ SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
file://0003-native_bindir.patch \
file://0004-Prettifying-some-output-with-pathlib.patch \

file://0005-Set-the-meson-command-to-use-when-we-know-what-it-is.patch \
-   file://validate-cpu.patch \
+   file://0001-Validate-cpu_family-3753.patch \
+   file://0002-Make-CPU-family-warnings-fatal.patch \
+   file://0003-Send-user-to-our-wiki-instead-of-Meson-bug-system.patch 
\
file://0001-mesonbuild-Recognise-risc-v-architecture.patch \
"
 
diff --git a/meta/recipes-devtools/meson/meson/validate-cpu.patch 
b/meta/recipes-devtools/meson/meson/0001-Validate-cpu_family-3753.patch
similarity index 55%
rename from meta/recipes-devtools/meson/meson/validate-cpu.patch
rename to meta/recipes-devtools/meson/meson/0001-Validate-cpu_family-3753.patch
index e7dad00d47..6b0d0ca588 100644
--- a/meta/recipes-devtools/meson/meson/validate-cpu.patch
+++ b/meta/recipes-devtools/meson/meson/0001-Validate-cpu_family-3753.patch
@@ -1,13 +1,7 @@
-Validate the passed CPU family (US: backport) and turn the upstream warning to
-an error (US: inappropriate).
-
-Upstream-Status: Backport
-Signed-off-by: Ross Burton 
-
-From 456f7ea48503731d50a2b7287a0f198b73b4fe61 Mon Sep 17 00:00:00 2001
+From 12fe95b1943eb832a54ba09274fa02c60d04f6b0 Mon Sep 17 00:00:00 2001
 From: Ross Burton 
 Date: Wed, 20 Jun 2018 13:45:44 +0100
-Subject: [PATCH 1/2] Validate cpu_family (#3753)
+Subject: [PATCH 1/3] Validate cpu_family (#3753)
 
 * environment: validate cpu_family in cross file
 
@@ -25,12 +19,16 @@ $ python3
 import platform; platform.machine()
 
 Partial fix for #3751
+
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
 ---
  mesonbuild/environment.py | 24 
- 1 file changed, 24 insertions(+)
+ run_unittests.py  | 18 ++
+ 2 files changed, 42 insertions(+)
 
 diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
-index 6920b8d6..091d92dc 100644
+index d02a837..678d009 100644
 --- a/mesonbuild/environment.py
 +++ b/mesonbuild/environment.py
 @@ -72,6 +72,22 @@ from .compilers import (
@@ -78,41 +76,35 @@ index 6920b8d6..091d92dc 100644
  if self.ok_type(res):
  self.config[s][entry] = res
  elif isinstance(res, list):
--- 
-2.11.0
-
-
-From 202e0199d3ffd2637f4dbee08f8351520f7dde3b Mon Sep 17 00:00:00 2001
-From: Ross Burton 
-Date: Tue, 3 Jul 2018 13:59:09 +0100
-Subject: [PATCH 2/2] Make CPU family warnings fatal
-

- mesonbuild/environment.py | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
-index 091d92dc..67177c1f 100644
 a/mesonbuild/environment.py
-+++ b/mesonbuild/environment.py
-@@ -228,7 +228,7 @@ def detect_cpu_family(compilers):
- # Add fixes here as bugs are reported.
- 
- if trial not in known_cpu_families:
--mlog.warning('Unknown CPU family %s, please report this at 
https://github.com/mesonbuild/meson/issues/new' % trial)
-+raise EnvironmentException('Unknown CPU family %s, see 
https://wiki.yoctoproject.org/wiki/Meson/UnknownCPU for directions.' % trial)
+diff --git a/run_unittests.py b/run_unittests.py
+index 3c215db..7185008 100755
+--- a/run_unittests.py
 b/run_unittests.py
+@@ -2065,6 +2065,24 @@ recommended as it can lead to undefined behaviour on 
some platforms''')
+ self.wipe()
  
- return trial
- 
-@@ -1043,7 +1043,7 @@ class CrossBuildInfo:
- raise EnvironmentException('Malformed value in cross file 
variable %s.' % entry)
  
- if entry == 'cpu_family' and res not in known_cpu_families:
--mlog.warning('Unknown CPU family %s, ple

[OE-core] [PATCHv2 2/2] meson: Support building allarch recipes again

2018-08-14 Thread Peter Kjellerstedt

This registers "allarch" as a known CPU family.

Signed-off-by: Peter Kjellerstedt 
---
Patch v2: Rebased on current master due to conflicts.

 meta/recipes-devtools/meson/meson.inc  |  1 +
 ...01-Support-building-allarch-recipes-again.patch | 28 ++
 2 files changed, 29 insertions(+)
 create mode 100644 
meta/recipes-devtools/meson/meson/0001-Support-building-allarch-recipes-again.patch

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
index c9e1e051c6..b5dfa2c2a2 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -15,6 +15,7 @@ SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
file://0002-Make-CPU-family-warnings-fatal.patch \
file://0003-Send-user-to-our-wiki-instead-of-Meson-bug-system.patch 
\
file://0001-mesonbuild-Recognise-risc-v-architecture.patch \
+   file://0001-Support-building-allarch-recipes-again.patch \
"
 
 SRC_URI[md5sum] = "1698f6526574839de5dcdc45e3f7d582"
diff --git 
a/meta/recipes-devtools/meson/meson/0001-Support-building-allarch-recipes-again.patch
 
b/meta/recipes-devtools/meson/meson/0001-Support-building-allarch-recipes-again.patch
new file mode 100644
index 00..f6dd230916
--- /dev/null
+++ 
b/meta/recipes-devtools/meson/meson/0001-Support-building-allarch-recipes-again.patch
@@ -0,0 +1,28 @@
+From d80d02a3ca6e21fa3d055c88c05234c2eb4db128 Mon Sep 17 00:00:00 2001
+From: Peter Kjellerstedt 
+Date: Thu, 26 Jul 2018 16:32:49 +0200
+Subject: [PATCH] Support building allarch recipes again
+
+This registers "allarch" as a known CPU family.
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Peter Kjellerstedt 
+---
+ mesonbuild/environment.py | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
+index a0580a2..712b1e8 100644
+--- a/mesonbuild/environment.py
 b/mesonbuild/environment.py
+@@ -73,6 +73,7 @@ from .compilers import (
+ build_filename = 'meson.build'
+ 
+ known_cpu_families = (
++'allarch',
+ 'aarch64',
+ 'arm',
+ 'e2k',
+-- 
+2.12.0
+
-- 
2.12.0

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

[OE-core] [PATCH] libunwind: Fix build with musl+security flags

2018-08-14 Thread Khem Raj

Fixes
src/os-linux.c:63: undefined reference to `__stack_chk_fail_local'

Signed-off-by: Khem Raj 
---
 meta/recipes-support/libunwind/libunwind_1.2.1.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/libunwind/libunwind_1.2.1.bb 
b/meta/recipes-support/libunwind/libunwind_1.2.1.bb
index 37a762486f..e7fb2b2190 100644
--- a/meta/recipes-support/libunwind/libunwind_1.2.1.bb
+++ b/meta/recipes-support/libunwind/libunwind_1.2.1.bb
@@ -21,3 +21,5 @@ ARM_INSTRUCTION_SET_armv4 = "arm"
 ARM_INSTRUCTION_SET_armv5 = "arm"
 
 LDFLAGS += "-Wl,-z,relro,-z,now ${@bb.utils.contains('DISTRO_FEATURES', 
'ld-is-gold', ' -fuse-ld=bfd ', '', d)}"
+
+SECURITY_LDFLAGS_append_libc-musl = " -lssp_nonshared"
-- 
2.18.0

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

[OE-core] [PATCHv4] package: skip strip on signed kernel modules

2018-08-14 Thread omar . ocampo . coronado

From: foocampo 

Kernel module signatures are outside the defined ELF container,
executing strip action on kernel modules removes the signature.
In order to keep the signature on kernel modules, avoid any strip
action on signed modules.

Fore more information check kernel.org admin-guide/module-signing.

Signed-off-by: Omar Ocampo 
---
 meta/lib/oe/package.py | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index fa3428ad61..e7eac19762 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -21,11 +21,15 @@ def runstrip(arg):
 os.chmod(file, newmode)
 
 stripcmd = [strip]
-
+skip_strip = False
 # kernel module
 if elftype & 16:
-stripcmd.extend(["--strip-debug", "--remove-section=.comment",
-"--remove-section=.note", "--preserve-dates"])
+if is_kernel_module_signed(file):
+bb.debug(1, "Skip strip on signed module %s" % file)
+skip_strip = True
+else:
+stripcmd.extend(["--strip-debug", "--remove-section=.comment",
+"--remove-section=.note", "--preserve-dates"])
 # .so and shared library
 elif ".so" in file and elftype & 8:
 stripcmd.extend(["--remove-section=.comment", 
"--remove-section=.note", "--strip-unneeded"])
@@ -36,7 +40,8 @@ def runstrip(arg):
 stripcmd.append(file)
 bb.debug(1, "runstrip: %s" % stripcmd)
 
-output = subprocess.check_output(stripcmd, stderr=subprocess.STDOUT)
+if not skip_strip:
+output = subprocess.check_output(stripcmd, stderr=subprocess.STDOUT)
 
 if newmode:
 os.chmod(file, origmode)
@@ -46,6 +51,15 @@ def is_kernel_module(path):
 with open(path) as f:
 return mmap.mmap(f.fileno(), 0, 
prot=mmap.PROT_READ).find(b"vermagic=") >= 0
 
+# Detect if .ko module is signed
+def is_kernel_module_signed(path):
+with open(path, "rb") as f:
+# 'Module signature appended' the string confirms a signature is 
present.
+# 28 bytes is the size of the string, regardless of the architecture.
+f.seek(-28, 2)
+module_tail = f.read()
+return "Module signature appended" in "".join(chr(c) for c in 
bytearray(module_tail))
+
 # Return type (bits):
 # 0 - not elf
 # 1 - ELF
-- 
2.18.0

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

[OE-core] [PATCH] linux-firmware: package Marvel usb 8997 firmware

2018-08-14 Thread Joshua Watt

Add package for the firmware required by the Marvell 8997 chipset when
connected over USB.

Signed-off-by: Joshua Watt 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index cf7abb0f96a..69f9a2adeab 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -232,6 +232,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-radeon-license ${PN}-radeon \
  ${PN}-marvell-license ${PN}-pcie8897 ${PN}-pcie8997 \
  ${PN}-sd8686 ${PN}-sd8688 ${PN}-sd8787 ${PN}-sd8797 ${PN}-sd8801 
${PN}-sd8887 ${PN}-sd8897 \
+ ${PN}-usb8997 \
  ${PN}-ti-connectivity-license ${PN}-wl12xx ${PN}-wl18xx \
  ${PN}-vt6656-license ${PN}-vt6656 \
  ${PN}-rtl-license ${PN}-rtl8188 ${PN}-rtl8192cu ${PN}-rtl8192ce 
${PN}-rtl8192su ${PN}-rtl8723 ${PN}-rtl8821 \
@@ -409,6 +410,7 @@ LICENSE_${PN}-sd8797 = "Firmware-Marvell"
 LICENSE_${PN}-sd8801 = "Firmware-Marvell"
 LICENSE_${PN}-sd8887 = "Firmware-Marvell"
 LICENSE_${PN}-sd8897 = "Firmware-Marvell"
+LICENSE_${PN}-usb8997 = "Firmware-Marvell"
 LICENSE_${PN}-marvell-license = "Firmware-Marvell"
 
 FILES_${PN}-marvell-license = "${nonarch_base_libdir}/firmware/LICENCE.Marvell"
@@ -443,6 +445,9 @@ FILES_${PN}-sd8887 = " \
 FILES_${PN}-sd8897 = " \
   ${nonarch_base_libdir}/firmware/mrvl/sd8897_uapsta.bin \
 "
+FILES_${PN}-usb8997 = " \
+  ${nonarch_base_libdir}/firmware/mrvl/usbusb8997_combo_v4.bin \
+"
 
 RDEPENDS_${PN}-sd8686 += "${PN}-marvell-license"
 RDEPENDS_${PN}-sd8688 += "${PN}-marvell-license"
@@ -451,6 +456,7 @@ RDEPENDS_${PN}-sd8797 += "${PN}-marvell-license"
 RDEPENDS_${PN}-sd8801 += "${PN}-marvell-license"
 RDEPENDS_${PN}-sd8887 += "${PN}-marvell-license"
 RDEPENDS_${PN}-sd8897 += "${PN}-marvell-license"
+RDEPENDS_${PN}-usb8997 += "${PN}-marvell-license"
 
 # For netronome
 LICENSE_${PN}-netronome = "Firmware-netronome"
-- 
2.17.1

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

[OE-core] ✗ patchtest: failure for package: skip strip on signed kernel modules (rev4)

2018-08-14 Thread Patchwork

== Series Details ==

Series: package: skip strip on signed kernel modules (rev4)
Revision: 4
URL   : https://patchwork.openembedded.org/series/13380/
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 e2b8a3d5a1)



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] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
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

Re: [OE-core] [PATCHv4] package: skip strip on signed kernel modules

2018-08-14 Thread Andre McCurdy

On Tue, Aug 14, 2018 at 3:33 PM,   wrote:
> From: foocampo 
>
> Kernel module signatures are outside the defined ELF container,
> executing strip action on kernel modules removes the signature.
> In order to keep the signature on kernel modules, avoid any strip
> action on signed modules.
>
> Fore more information check kernel.org admin-guide/module-signing.

An earlier version of this patch has already been merged:

  
http://git.openembedded.org/openembedded-core/commit/?id=4c47e5f171fa2603355e2f9183065ce8137a18c7

In general, you should always at least rebase to the latest upstream
master branch before (re)submitting a patch. Checking what's upcoming
in master-next is often useful too.

Also, when sending updates to a previously submitted patch, it's
helpful to provide a brief description of what's changed (via a
comment below the "---" line). In this case it looks like you only
added some comments and updated the commit message?

> Signed-off-by: Omar Ocampo 

The Author and Signed-off-by lines in your patches are different.
Maybe double check your local git config before sending more patches.
Author should be your name, not a user name.

> ---
>  meta/lib/oe/package.py | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
> index fa3428ad61..e7eac19762 100644
> --- a/meta/lib/oe/package.py
> +++ b/meta/lib/oe/package.py
> @@ -21,11 +21,15 @@ def runstrip(arg):
>  os.chmod(file, newmode)
>
>  stripcmd = [strip]
> -
> +skip_strip = False
>  # kernel module
>  if elftype & 16:
> -stripcmd.extend(["--strip-debug", "--remove-section=.comment",
> -"--remove-section=.note", "--preserve-dates"])
> +if is_kernel_module_signed(file):
> +bb.debug(1, "Skip strip on signed module %s" % file)
> +skip_strip = True
> +else:
> +stripcmd.extend(["--strip-debug", "--remove-section=.comment",
> +"--remove-section=.note", "--preserve-dates"])
>  # .so and shared library
>  elif ".so" in file and elftype & 8:
>  stripcmd.extend(["--remove-section=.comment", 
> "--remove-section=.note", "--strip-unneeded"])
> @@ -36,7 +40,8 @@ def runstrip(arg):
>  stripcmd.append(file)
>  bb.debug(1, "runstrip: %s" % stripcmd)
>
> -output = subprocess.check_output(stripcmd, stderr=subprocess.STDOUT)
> +if not skip_strip:
> +output = subprocess.check_output(stripcmd, stderr=subprocess.STDOUT)
>
>  if newmode:
>  os.chmod(file, origmode)
> @@ -46,6 +51,15 @@ def is_kernel_module(path):
>  with open(path) as f:
>  return mmap.mmap(f.fileno(), 0, 
> prot=mmap.PROT_READ).find(b"vermagic=") >= 0
>
> +# Detect if .ko module is signed
> +def is_kernel_module_signed(path):
> +with open(path, "rb") as f:
> +# 'Module signature appended' the string confirms a signature is 
> present.
> +# 28 bytes is the size of the string, regardless of the architecture.
> +f.seek(-28, 2)
> +module_tail = f.read()
> +return "Module signature appended" in "".join(chr(c) for c in 
> bytearray(module_tail))
> +
>  # Return type (bits):
>  # 0 - not elf
>  # 1 - ELF
> --
> 2.18.0
>
> --
> ___
> 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] tune-strongarm1100.inc: restore specific tuning

2018-08-14 Thread Andrea Adami

Since commit

 a11bdc36a1be
 tune-*: define more generic DEFAULTTUNE to share feed between machines

we are using armv4 to share binary feeds.

As of today, there are no public feeds for the legacy devices so let's prefer
the optimal tuning.

Signed-off-by: Andrea Adami 
---
 meta/conf/machine/include/tune-strongarm1100.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/tune-strongarm1100.inc 
b/meta/conf/machine/include/tune-strongarm1100.inc
index 80cfb8a..c8b62c4 100644
--- a/meta/conf/machine/include/tune-strongarm1100.inc
+++ b/meta/conf/machine/include/tune-strongarm1100.inc
@@ -1,4 +1,4 @@
-DEFAULTTUNE ?= "armv4"
+DEFAULTTUNE ?= "strongarm"
 
 require conf/machine/include/arm/arch-armv4.inc
 
-- 
2.7.4

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

Re: [OE-core] Yocto Project Status WW33’18

2018-08-14 Thread akuster808



On 08/14/2018 07:46 AM, Jolley, Stephen K wrote:
>
> Current Dev Position: YP 2.6 M3.
>
> Next Deadline: YP 2.6 M3 Build Target is Aug. 27, 2018
>
Thanks for the updates Steven.
>
>  
>
> SWAT Team Rotation:
>
> · SWAT lead is currently: Maxin
>
> · SWAT team rotation: Maxin -> Chen on Aug. 17, 2018
>
> · SWAT team rotation: Chen -> Paul on Aug. 24, 2018
>
> · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>  
>
> Key Status/Updates:
>
> · YP 2.6 M2 released on 8/10/18.
>
> · YP 2.5.1 is in QA. See
> https://wiki.yoctoproject.org/wiki/2.5_QA_Status.  It is 98% complete
> and should finish soon.
>
> · A summary of sstate usage was added to the initial build
> output which gives numbers for the fraction of artefacts which are
> being reused. We may need to tweak the presentation to the user but
> its good information to provide and feedback on it is welcome.
>
> · Glibc 2.28 is proving to have a number of issues to
> integrate including the significant size increase of its locale data,
> creating locale archives is likely the way forward for images reducing
> their size in core-image-lsb-sdk from ~900MB to ~220MB. The patches
> remain -next whilst fixes for issues are confirmed.
>
> · Many other miscellaneous fixes were merged covering many
> aspects of the system.
>
> · A potential DoS style issue was found in the bitbake
> checksum code and in fixing it the improvement of the checksumming
> code measurably improved (Thanks Ross!)
>
Thanks Ross.

> · The sstate equivalency server work from Joshua/Garmin has
> review still pending but the related persist_data improvements are
> queued for merging.
>
> · The kernel-devsrc rework from Bruce/Windriver is pending
> patch resubmission.
>
> · 2.4 (rocko) series stabilization continues for the next
> point release 2.4.4
>
>  
>
> Planned Releases for YP 2.6:
>
> · YP 2.6 M3 Build Target is Aug. 27, 2018
>
> · YP 2.6 M3 Release Target is Sept. 7, 2018
>
Is M3 feature freeze?

- Armin

> · YP 2.6 M4 Build Target is Oct. 1, 2018
>
> · YP 2.6 M4 Release Target is Oct. 26, 2018
>
>  
>
> Planned upcoming dot releases:
>
> · YP 2.5.1 (Sumo) is in QA.
>
> · YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done.
>
> · YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done.
>
>  
>
> Tracking Metrics:
>
> · WDD 2592 (last week
> 2590)(https://wiki.yoctoproject.org/charts/combo.html)
>
> · Poky Patch Metrics  
>
> o    Total patches found: 1616 (last week 1608)
>
> o    Percentage of patches in the Pending State: 736 (46%) [last week
> 730 (45%)]
>

>  
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features
>
>  
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>  
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>
>  
>
> Thanks,
>
>  
>
> */Stephen K. Jolley/**//*
>
> *Yocto Project Program Manager*
>
> *INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 *
>
> (    *Cell*:    (208) 244-4460
>
> * *Email*: _stephen.k.jolley@intel.com_
>
>  
>
>
>

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

Re: [OE-core] Cherry-pick to Sumo (was: [PATCHv2 1/2] oe-pkgdata-util: Make parse_pkgdatafile() support package suffixed vars)

2018-08-14 Thread akuster808




On 08/13/2018 05:14 AM, Peter Kjellerstedt wrote:
> *ping*
they are in stable/sumo-nmut for testing.

- armin
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org > core-boun...@lists.openembedded.org> On Behalf Of Peter Kjellerstedt
>> Sent: den 7 juni 2018 16:05
>> To: akuster808 
>> Cc: openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] Cherry-pick to Sumo (was: [PATCHv2 1/2] oe-
>> pkgdata-util: Make parse_pkgdatafile() support package suffixed vars)
>>
>>> -Original Message-
>>> From: akuster808 [mailto:akuster...@gmail.com]
>>> Sent: den 3 juni 2018 17:13
>>> To: Peter Kjellerstedt ; openembedded-
>>> c...@lists.openembedded.org
>>> Subject: Re: [OE-core] Cherry-pick to Sumo (was: [PATCHv2 1/2] oe-
>>> pkgdata-util: Make parse_pkgdatafile() support package suffixed vars)
>>>
>>> On 06/02/2018 12:48 PM, Peter Kjellerstedt wrote:
 These two patches, in addition to "oe-pkgdata-util: lookup-recipe,
 package-info: Don't finish prematurely" (commit 32c2a2dd) that is
 already on master, need to be cherry-picked to the sumo branch as
 well. Without them, `oe-pkgdata-util package-info ...` is more or
 less broken.

 //Peter
>>> Thanks peter. I hope to remember to back port them once they hit
>>> master.
>>>
>>> -armin
>> They have hit master now. The commits I want cherry-picked to Sumo
>> from master are:
>>
>> 32c2a2dd oe-pkgdata-util: lookup-recipe, package-info: Don't finish
>> prematurely
>> 38f82842 oe-pkgdata-util: Make parse_pkgdatafile() support package
>> suffixed vars
>> cd195bdf oe-pkgdata-util: package-info: Re-add support for the --extra
>> option
>>
>> //Peter
>>
>> --
>> ___
>> 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/2] libdrm: Upgrade to 2.4.93

2018-08-14 Thread Khem Raj

Signed-off-by: Khem Raj 
---
 .../drm/{libdrm_2.4.92.bb => libdrm_2.4.93.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/drm/{libdrm_2.4.92.bb => libdrm_2.4.93.bb} (95%)

diff --git a/meta/recipes-graphics/drm/libdrm_2.4.92.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.93.bb
similarity index 95%
rename from meta/recipes-graphics/drm/libdrm_2.4.92.bb
rename to meta/recipes-graphics/drm/libdrm_2.4.93.bb
index 9ef31010a4..9219d87e4e 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.92.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.93.bb
@@ -12,8 +12,8 @@ DEPENDS = "libpthread-stubs"
 
 SRC_URI = "http://dri.freedesktop.org/libdrm/${BP}.tar.bz2 \
file://musl-ioctl.patch"
-SRC_URI[md5sum] = "f9b00d985f82d0be6ecc20c799acc89e"
-SRC_URI[sha256sum] = 
"e9e48fdb4de139dc4d9880aa1473158a16ff6aff63d14341367bd30a51ff39fa"
+SRC_URI[md5sum] = "0ba45ad1551b2c1b6df0797a3e65f827"
+SRC_URI[sha256sum] = 
"6e84d1dc9548a76f20b59a85cf80a0b230cd8196084f5243469d9e65354fcd3c"
 
 inherit meson pkgconfig manpages
 
-- 
2.18.0

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

[OE-core] [PATCH 2/2] security_flags: Add PIC to cflags for some recipes on ppc

2018-08-14 Thread Khem Raj

Fixes issues related out of range R_PPC_REL24
e.g.
/usr/lib/xorg/modules/input/libinput_drv.so: /usr/lib/libinput.so.10: 
R_PPC_REL24 relocation at 0x0e8602c4 for symbol `libevdev_has_event_code' out 
of range

Signed-off-by: Khem Raj 
---
 meta/conf/distro/include/security_flags.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/conf/distro/include/security_flags.inc 
b/meta/conf/distro/include/security_flags.inc
index 6245e89ada..52e1e4ebc5 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -30,6 +30,9 @@ SECURITY_X_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro"
 # powerpc does not get on with pie for reasons not looked into as yet
 SECURITY_CFLAGS_powerpc = "-fstack-protector-strong ${lcl_maybe_fortify} 
${SECURITY_NOPIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libgcc_powerpc = ""
+SECURITY_CFLAGS_append_powerpc_pn-libdrm = " -fPIC -DPIC"
+SECURITY_CFLAGS_append_powerpc_pn-libinput = " -fPIC -DPIC"
+SECURITY_CFLAGS_append_powerpc_pn-at-spi2-core = " -fPIC -DPIC"
 GCCPIE_powerpc = ""
 GLIBCPIE_powerpc = ""
 
-- 
2.18.0

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

[OE-core] [PATCH] swig: fix gcc8 warnings for cast between incompatible function types

2018-08-14 Thread Yi Zhao

We got an error when building setools in meta-selinux:
setools/policyrep/qpol_wrap.c:1819:23:
error: cast between incompatible function types from 'PyObject * (*)(PyObject 
*)'
{aka 'struct _object * (*)(struct _object *)'} to 'PyObject * (*)(PyObject *, 
PyObject *)'
{aka 'struct _object * (*)(struct _object *, struct _object *)'} 
[-Werror=cast-function-type]
{(char *)"disown", (PyCFunction)SwigPyObject_disown, METH_NOARGS, (char 
*)"releases ownership of the pointer"},

This is a swig issue. See: https://github.com/swig/swig/issues/1259
Backport a patch from upstream to fix it.

Signed-off-by: Yi Zhao 
---
 ...n-Fix-new-GCC8-warnings-in-generated-code.patch | 191 +
 meta/recipes-devtools/swig/swig_3.0.12.bb  |   1 +
 2 files changed, 192 insertions(+)
 create mode 100644 
meta/recipes-devtools/swig/swig/Python-Fix-new-GCC8-warnings-in-generated-code.patch

diff --git 
a/meta/recipes-devtools/swig/swig/Python-Fix-new-GCC8-warnings-in-generated-code.patch
 
b/meta/recipes-devtools/swig/swig/Python-Fix-new-GCC8-warnings-in-generated-code.patch
new file mode 100644
index 000..a913859
--- /dev/null
+++ 
b/meta/recipes-devtools/swig/swig/Python-Fix-new-GCC8-warnings-in-generated-code.patch
@@ -0,0 +1,191 @@
+From b6c0ef4b8f6e5c089ac7104b3aaba8f1d17b8b82 Mon Sep 17 00:00:00 2001
+From: Olly Betts 
+Date: Mon, 11 Jun 2018 15:51:53 +1200
+Subject: [PATCH] [Python] Fix new GCC8 warnings in generated code
+
+Avoid casts between incompatible function types where possible (when
+keyword args are in use, it is not possible to avoid such warnings as
+they are inherent in the design of Python's C API in that particular
+case).  Fixes #1259.
+
+Upstream-Status: Backport
+[https://github.com/swig/swig/commit/7f9883011029674553a2a4b623d459f02b512458]
+
+Signed-off-by: Yi Zhao 
+---
+ Lib/python/pyinit.swg |  4 ++--
+ Lib/python/pyrun.swg  | 34 ++
+ Source/Modules/python.cxx | 26 +-
+ 3 files changed, 41 insertions(+), 23 deletions(-)
+
+diff --git a/Lib/python/pyinit.swg b/Lib/python/pyinit.swg
+index 2cc5828..6bf68c1 100644
+--- a/Lib/python/pyinit.swg
 b/Lib/python/pyinit.swg
+@@ -368,8 +368,8 @@ SWIG_init(void) {
+ (char *)"this", &SwigPyBuiltin_ThisClosure, NULL, NULL, NULL
+   };
+   static SwigPyGetSet thisown_getset_closure = {
+-(PyCFunction) SwigPyObject_own,
+-(PyCFunction) SwigPyObject_own
++SwigPyObject_own,
++SwigPyObject_own
+   };
+   static PyGetSetDef thisown_getset_def = {
+ (char *)"thisown", SwigPyBuiltin_GetterClosure, 
SwigPyBuiltin_SetterClosure, NULL, &thisown_getset_closure
+diff --git a/Lib/python/pyrun.swg b/Lib/python/pyrun.swg
+index ab1237f..3d0b1b3 100644
+--- a/Lib/python/pyrun.swg
 b/Lib/python/pyrun.swg
+@@ -465,6 +465,14 @@ SwigPyObject_repr(SwigPyObject *v, PyObject *args)
+   return repr;  
+ }
+ 
++/* We need a version taking two PyObject* parameters so it's a valid
++ * PyCFunction to use in swigobject_methods[]. */
++SWIGRUNTIME PyObject *
++SwigPyObject_repr2(PyObject *v, PyObject *SWIGUNUSEDPARM(args))
++{
++  return SwigPyObject_repr((SwigPyObject*)v);
++}
++
+ SWIGRUNTIME int
+ SwigPyObject_compare(SwigPyObject *v, SwigPyObject *w)
+ {
+@@ -594,11 +602,7 @@ SwigPyObject_append(PyObject* v, PyObject* next)
+ }
+ 
+ SWIGRUNTIME PyObject* 
+-#ifdef METH_NOARGS
+-SwigPyObject_next(PyObject* v)
+-#else
+ SwigPyObject_next(PyObject* v, PyObject *SWIGUNUSEDPARM(args))
+-#endif
+ {
+   SwigPyObject *sobj = (SwigPyObject *) v;
+   if (sobj->next) {
+@@ -633,6 +637,20 @@ SwigPyObject_acquire(PyObject* v, PyObject 
*SWIGUNUSEDPARM(args))
+   return SWIG_Py_Void();
+ }
+ 
++#ifdef METH_NOARGS
++static PyObject*
++SwigPyObject_disown2(PyObject* v, PyObject *SWIGUNUSEDPARM(args))
++{
++  return SwigPyObject_disown(v);
++}
++
++static PyObject*
++SwigPyObject_acquire2(PyObject* v, PyObject *SWIGUNUSEDPARM(args))
++{
++  return SwigPyObject_acquire(v);
++}
++#endif
++
+ SWIGINTERN PyObject*
+ SwigPyObject_own(PyObject *v, PyObject *args)
+ {
+@@ -673,12 +691,12 @@ SwigPyObject_own(PyObject *v, PyObject *args)
+ #ifdef METH_O
+ static PyMethodDef
+ swigobject_methods[] = {
+-  {(char *)"disown",  (PyCFunction)SwigPyObject_disown,  METH_NOARGS,  (char 
*)"releases ownership of the pointer"},
+-  {(char *)"acquire", (PyCFunction)SwigPyObject_acquire, METH_NOARGS,  (char 
*)"acquires ownership of the pointer"},
++  {(char *)"disown",  (PyCFunction)SwigPyObject_disown2, METH_NOARGS,  (char 
*)"releases ownership of the pointer"},
++  {(char *)"acquire", (PyCFunction)SwigPyObject_acquire2,METH_NOARGS,  (char 
*)"acquires ownership of the pointer"},
+   {(char *)"own", (PyCFunction)SwigPyObject_own, METH_VARARGS, (char 
*)"returns/sets ownership of the pointer"},
+   {(char *)"append",  (PyCFunction)SwigPyObject_append,  METH_O,   (char 
*)"appends another 'this' object"},
+   {(char *)"next",(PyCFunction)SwigPyObject_next,METH_NOARGS,  (char 
*)"retur

[OE-core] [PATCH 0/1] glibc: re-package for libnss-db

2018-08-14 Thread Chen Qi

*** BLURB HERE ***
The following changes since commit 63a4ff7cf5f7d1671ab85800bc2212dd9cd9748d:

  bitbake: checksum: sanity check path when recursively checksumming 
(2018-08-14 16:32:48 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/libnss-db
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/libnss-db

Jackie Huang (1):
  glibc: re-package for libnss-db

 meta/recipes-core/glibc/glibc-package.inc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
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] glibc: re-package for libnss-db

2018-08-14 Thread Chen Qi

From: Jackie Huang 

On other distros like ubuntu/centos, libnss-db usually provides:
- The libraries
- The Makefile to create database
  (in /var/db for centos, /var/lib/misc/ for ubuntu)
- The makedb command (it's in glibc-common for centos7)

What we had is:
- The libraries are in glibc-extra-nss
- The Makefile is removed
- The makedb command is in glibc-utils (lack of dependency)

So when glibc-extra-nss is installed but glibc-utils is not,
we see error like:
nscd[165]: 165 checking for monitored file `/var/db/group.db': No such file or 
directory
nscd[165]: 165 checking for monitored file `/var/db/passwd.db': No such file or 
directory

And there is not an easy way to create these databases.

To fix the issue:
- Re-package the libraries into libnss-db
- Don't remove the Makefile and add it in libnss-db
- Add RDEPENDS for libnss-db on glibc-utils and make

Notes:
For external toolchain, an extra package 'libnss-db' need to be provided
If replacing glibc from core.

Signed-off-by: Jackie Huang 
Signed-off-by: Chen Qi 
---
 meta/recipes-core/glibc/glibc-package.inc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 8ac01ce..305094f 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -1,6 +1,6 @@
 INHIBIT_SYSROOT_STRIP = "1"
 
-PACKAGES = "${PN}-dbg catchsegv sln nscd ldd tzcode glibc-thread-db ${PN}-pic 
libcidn libmemusage libsegfault ${PN}-pcprofile libsotruss ${PN} ${PN}-utils 
glibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc"
+PACKAGES = "${PN}-dbg catchsegv sln nscd ldd tzcode glibc-thread-db ${PN}-pic 
libcidn libmemusage libnss-db libsegfault ${PN}-pcprofile libsotruss ${PN} 
${PN}-utils glibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc"
 
 # The ld.so in this glibc supports the GNU_HASH
 RPROVIDES_${PN} = "eglibc rtld(GNU_HASH)"
@@ -23,6 +23,8 @@ FILES_ldd = "${bindir}/ldd"
 FILES_libsegfault = "${base_libdir}/libSegFault*"
 FILES_libcidn = "${base_libdir}/libcidn-*.so ${base_libdir}/libcidn.so.*"
 FILES_libmemusage = "${base_libdir}/libmemusage.so"
+FILES_libnss-db = "${base_libdir}/libnss_db.so.* ${base_libdir}/libnss_db-*.so 
${localstatedir}/db/Makefile"
+RDEPENDS_libnss-db = "${PN}-utils make"
 FILES_glibc-extra-nss = "${base_libdir}/libnss_*-*.so 
${base_libdir}/libnss_*.so.*"
 FILES_sln = "${base_sbindir}/sln"
 FILES_${PN}-pic = "${libdir}/*_pic.a ${libdir}/*_pic.map 
${libdir}/libc_pic/*.o"
@@ -59,7 +61,6 @@ inherit libc-common multilib_header
 
 do_install_append () {
rm -f ${D}${sysconfdir}/localtime
-   rm -rf ${D}${localstatedir}
 
# remove empty glibc dir
if [ -d ${D}${libexecdir} ]; then
-- 
1.9.1

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

52 matches

Mail list logo