Re: [OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Ankur Tyagi
Hi Adrian,

Thanks for explaining things and helping me out.

Once I have stable builds then will try your suggestion as well.

Ankur

On Mon, Nov 25, 2019 at 1:10 PM Adrian Bunk  wrote:

> On Mon, Nov 25, 2019 at 07:26:58PM +, Ross Burton wrote:
> > On 25/11/2019 18:37, Ankur Tyagi wrote:
> > > Hi,
> > >
> > > Based upon "thud" branch, I created core-image-minimal for am335x-evm
> > > board and resulting image size is very big(71M)
> >
> > If disk size is important then a good first step is to use musl instead
> of
> > glibc:
> >
> > TCLIBC = "musl"
> >...
>
> musl is mainly useful for tiny systems, a 40 MB partition is such a huge
> amount of space that the size of the C library no longer matters much.
>
> The size benefit of replacing glibc with musl is around 2 MB.
>
> A partition with an -Os build of Yocto with glibc+systemd (sic)
> is around 9 MB, together with bootloader and kernel this all
> fits in a 16 MB flash. Use compression for kernel and root
> filesystem and everything fits in a 8 MB flash.
>
> > Ross
>
> cu
> Adrian
> --
> ___
> 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] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Ankur Tyagi
Hi Ross,

I just used arago distro as it is but you are right, once I have stable
builds
with default configuration then I will try your suggestion.

Thanks for your help

Ankur

On Mon, Nov 25, 2019 at 12:58 PM Ross Burton  wrote:

> On 25/11/2019 20:22, Ankur Tyagi wrote:
> > # Select external binary prebuilt Arm toolchain
> > TCMODE = "external-arm"
> > TCLIBC = "external-arm-toolchain"
>
> FWIW, I don't see what the value in external toolchains actually is.
> You might get better results by simply setting:
>
> TCMODE = "default"
> TCLIB = "glibc"
>
> (or TCLIBC="musl" if you want to save even more space)
>
> Ross
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCHv3] cronie:upgrade 1.5.4 -> 1.5.5

2019-11-25 Thread Zang Ruochen
From: Wang Mingyu 

-Added PACKAGECONFIG to solve compilation problems with musl.

Signed-off-by: Wang Mingyu 
---
 meta/recipes-extended/cronie/{cronie_1.5.4.bb => cronie_1.5.5.bb} | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/cronie/{cronie_1.5.4.bb => cronie_1.5.5.bb} (93%)

diff --git a/meta/recipes-extended/cronie/cronie_1.5.4.bb 
b/meta/recipes-extended/cronie/cronie_1.5.5.bb
similarity index 93%
rename from meta/recipes-extended/cronie/cronie_1.5.4.bb
rename to meta/recipes-extended/cronie/cronie_1.5.5.bb
index d35c667..82cd428 100644
--- a/meta/recipes-extended/cronie/cronie_1.5.4.bb
+++ b/meta/recipes-extended/cronie/cronie_1.5.5.bb
@@ -25,8 +25,8 @@ SRC_URI = 
"https://github.com/cronie-crond/cronie/releases/download/cronie-${PV}
 PAM_SRC_URI = "file://crond_pam_config.patch"
 PAM_DEPS = "libpam libpam-runtime pam-plugin-access pam-plugin-loginuid"
 
-SRC_URI[md5sum] = "20233b96997e17a142e1fbe0d7ce8223"
-SRC_URI[sha256sum] = 
"af8970559cad4262f8ffd7ec72abf682d2dcce04fdfb8f206a71d96566aba882"
+SRC_URI[md5sum] = "351a37d0b5bd0144816724b4482747ad"
+SRC_URI[sha256sum] = 
"be34c79505e5544323281854744b9955ff16b160ee569f9df7c0dddae5720eac"
 
 inherit autotools update-rc.d useradd systemd
 
@@ -34,6 +34,7 @@ PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 
'pam', d)}"
 
 PACKAGECONFIG[audit] = "--with-audit,--without-audit,audit,"
 PACKAGECONFIG[pam] = "--with-pam,--without-pam,libpam,${PAM_DEPS}"
+PACKAGECONFIG[anacron] = "--enable-anacron,--disable-anacron,anacron"
 
 INITSCRIPT_NAME = "crond"
 INITSCRIPT_PARAMS = "start 90 2 3 4 5 . stop 60 0 1 6 ."
-- 
2.7.4



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


Re: [OE-core] [PATCH] multilib.bbclass: fix qa warning of kernel-devicetree

2019-11-25 Thread Kang Kai

On 2019/11/19 上午11:15, kai.k...@windriver.com wrote:

From: Kai Kang 

When kernel-devicetree is in RRECOMMENDS such as via variable
MACHINE_EXTRA_RRECOMMENDS for some bsp, it shows QA warning of multilib:

| WARNING: lib32-packagegroup-base-1.0-r83 do_package: QA Issue:
| lib32-packagegroup-base package lib32-packagegroup-machine-base
| - suspicious values 'kernel-devicetree' in RRECOMMENDS [multilib]

Add kernel-devicetree to exceptions to fix the QA issue. Because there
are already 3 kernel related criteria, simplify them by judging package
names whether start with 'kernel-'. And also refactor to remove
duplicate 'not'.


Any comment please?

Regards,
Kai




Signed-off-by: Kai Kang 
---
  meta/classes/multilib.bbclass | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 1a9295d36f..ee677da1e2 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -184,11 +184,12 @@ python do_package_qa_multilib() {
  for i in values:
  if i.startswith('virtual/'):
  i = i[len('virtual/'):]
-if (not i.startswith('kernel-module')) and (not 
i.startswith(mlprefix)) and \
-(not 'cross-canadian' in i) and (not 
i.startswith("nativesdk-")) and \
-(not i.startswith("rtld")) and (not 
i.startswith('kernel-vmlinux')) \
-and (not i.startswith("kernel-image")) and (not 
i.startswith("/")):
+
+if (not (i.startswith(mlprefix) or i.startswith("kernel-") \
+or ('cross-canadian' in i) or i.startswith("nativesdk-") \
+or i.startswith("rtld") or i.startswith("/"))):
  candidates.append(i)
+
  if len(candidates) > 0:
  msg = "%s package %s - suspicious values '%s' in %s" \
 % (d.getVar('PN'), pkg, ' '.join(candidates), var)



--
Kai Kang

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


Re: [OE-core] [PATCH v2] cmake-native:upgrade 3.15.3 -> 3.15.5

2019-11-25 Thread Wang, Mingyu
Hi, Alex

OK, I will remake the patch of cmake and cmake-native and resubmit.

Wang


From: Alexander Kanavin [mailto:alex.kana...@gmail.com]
Sent: Friday, November 22, 2019 7:56 PM
To: Wang, Mingyu/王 鸣瑜 
Cc: OE-core 
Subject: Re: [OE-core] [PATCH v2] cmake-native:upgrade 3.15.3 -> 3.15.5

On Fri, 22 Nov 2019 at 10:17, Wang Mingyu 
mailto:wan...@cn.fujitsu.com>> wrote:
 .../cmake/{cmake-native_3.15.3.bb => 
cmake-native_3.15.5.bb}  | 0
 meta/recipes-devtools/cmake/cmake.inc | 4 ++--

You need to rename the target recipe as well.

Alex


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


Re: [OE-core] [PATCH 3/3] libcap-ng: fix built failure with some external toolchains due to missing pthread

2019-11-25 Thread Christopher Larson
It seems like libcap wants to support use of pthread by the linking application 
without mandating it, so we can’t pass -pthread, and I’m not sure a configure 
check would help, unless it wants to pull in pthread unconditionally. But I may 
be misunderstanding the libcap commits, and am *definitely* not a threading 
expert :)
On Nov 25, 2019, 3:27 PM -0700, Khem Raj , wrote:
> On Mon, Nov 25, 2019 at 2:13 PM Christopher Larson  wrote:
> >
> > From: Christopher Larson 
> >
> > The libcap-ng build doesn't pass -pthread and can fail to link.
> >
>
> perhaps, adding a configure time check for pthread.h would be possible
>
> AC_CHECK_HEADERS(pthread.h, [], [AC_MSG_WARN(pthread.h not found,
> pthread_atfork disabled.)])
>
> then include pthread.h inside conditional like below in source files.
>
> #ifdef HAVE_PTHREAD_H
> #endif
>
>
>
> > Signed-off-by: Christopher Larson 
> > ---
> > meta/recipes-support/libcap-ng/libcap-ng.inc | 1 +
> > .../libcap-ng/revert-pthread_atfork-fix.patch | 56 ++
> > 2 files changed, 57 insertions(+)
> > create mode 100644 
> > meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch
> >
> > diff --git a/meta/recipes-support/libcap-ng/libcap-ng.inc 
> > b/meta/recipes-support/libcap-ng/libcap-ng.inc
> > index aec83896e4..46d37e6807 100644
> > --- a/meta/recipes-support/libcap-ng/libcap-ng.inc
> > +++ b/meta/recipes-support/libcap-ng/libcap-ng.inc
> > @@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = 
> > "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
> >
> > SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz 
> > \
> > file://python.patch \
> > + file://revert-pthread_atfork-fix.patch \
> > "
> >
> > SRC_URI[md5sum] = "57dc267e2949cdecb651a929f9206572"
> > diff --git 
> > a/meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch 
> > b/meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch
> > new file mode 100644
> > index 00..d3f7790b1e
> > --- /dev/null
> > +++ 
> > b/meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch
> > @@ -0,0 +1,56 @@
> > +From 81dc82393fae9851397fa5d94094434aa1d5c3d1 Mon Sep 17 00:00:00 2001
> > +From: Christopher Larson 
> > +Date: Thu, 14 Nov 2019 21:13:24 +0500
> > +Subject: [PATCH] Revert "Fix usage of pthread_atfork a whole different way"
> > +
> > +This reverts commit 08a09cba90f3d960c080a20833fb8c0908f1cea6.
> > +
> > +The fix was breaking builds with some toolchains.
> > +
> > +Signed-off-by: Christopher Larson 
> > +---
> > + src/Makefile.am | 2 +-
> > + src/cap-ng.c | 12 +++-
> > + 2 files changed, 12 insertions(+), 2 deletions(-)
> > +
> > +diff --git a/src/Makefile.am b/src/Makefile.am
> > +index 5a66d4e..d46d02b 100644
> > +--- a/src/Makefile.am
> >  b/src/Makefile.am
> > +@@ -34,5 +34,5 @@ noinst_HEADERS = captab.h
> > + libcap_ng_la_SOURCES = cap-ng.c lookup_table.c
> > + libcap_ng_la_LIBADD =
> > + libcap_ng_la_DEPENDENCIES = $(libcap_ng_la_SOURCES) ../config.h
> > +-libcap_ng_la_LDFLAGS = -Wl,-z,relro
> > ++libcap_ng_la_LDFLAGS = -Wl,-z,relro -Wl,-z,nodelete
> > +
> > +diff --git a/src/cap-ng.c b/src/cap-ng.c
> > +index 35fcd7a..ed31afa 100644
> > +--- a/src/cap-ng.c
> >  b/src/cap-ng.c
> > +@@ -155,6 +155,15 @@ static __thread struct cap_ng m = { 1,
> > + CAPNG_NEW,
> > + {0, 0} };
> > +
> > ++
> > ++/*
> > ++ * The pthread_atfork function is being made weak so that we can use it
> > ++ * if the program is linked with pthreads and not requiring it for
> > ++ * everything that uses libcap-ng.
> > ++ */
> > ++extern int __attribute__((weak)) pthread_atfork(void (*prepare)(void),
> > ++ void (*parent)(void), void (*child)(void));
> > ++
> > + /*
> > + * Reset the state so that init gets called to erase everything
> > + */
> > +@@ -166,7 +175,8 @@ static void deinit(void)
> > + static void init_lib(void) __attribute__ ((constructor));
> > + static void init_lib(void)
> > + {
> > +- pthread_atfork(NULL, NULL, deinit);
> > ++ if (pthread_atfork)
> > ++ pthread_atfork(NULL, NULL, deinit);
> > + }
> > +
> > + static void init(void)
> > --
> > 2.11.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


Re: [OE-core] [PATCH 2/3] dosfstools: fix CP437 error from `dosfsck -l`

2019-11-25 Thread Christopher Larson
Good call, no idea how I missed that one.
On Nov 25, 2019, 3:28 PM -0700, Khem Raj , wrote:
> On Mon, Nov 25, 2019 at 2:12 PM Christopher Larson  wrote:
> >
> > From: Christopher Larson 
> >
> > Fix this error seen when using dosfsck -l to list fs contents:
> >
> > CP437: Invalid argument
> >
> > Signed-off-by: Christopher Larson 
> > ---
> > meta/recipes-devtools/dosfstools/dosfstools_4.1.bb | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb 
> > b/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
> > index 69aa81af44..c99d2019c8 100644
> > --- a/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
> > +++ b/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
> > @@ -23,3 +23,6 @@ EXTRA_OECONF = "--without-udev --enable-compat-symlinks"
> > CFLAGS += "-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
> >
> > BBCLASSEXTEND = "native"
> > +
> > +# Add codepage437 to avoid error from `dosfsck -l`
> > +RRECOMMENDS_${PN}_append_libc-glibc += "glibc-gconv-ibm437"
>
> I think += should be dropped
>
> > --
> > 2.11.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] ✗ patchtest: failure for "acpica: correct flex/bison dep..." and 2 more

2019-11-25 Thread Patchwork
== Series Details ==

Series: "acpica: correct flex/bison dep..." and 2 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/21349/
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 Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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] [PATCH 2/3] dosfstools: fix CP437 error from `dosfsck -l`

2019-11-25 Thread Khem Raj
On Mon, Nov 25, 2019 at 2:12 PM Christopher Larson  wrote:
>
> From: Christopher Larson 
>
> Fix this error seen when using dosfsck -l to list fs contents:
>
> CP437: Invalid argument
>
> Signed-off-by: Christopher Larson 
> ---
>  meta/recipes-devtools/dosfstools/dosfstools_4.1.bb | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb 
> b/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
> index 69aa81af44..c99d2019c8 100644
> --- a/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
> +++ b/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
> @@ -23,3 +23,6 @@ EXTRA_OECONF = "--without-udev --enable-compat-symlinks"
>  CFLAGS += "-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
>
>  BBCLASSEXTEND = "native"
> +
> +# Add codepage437 to avoid error from `dosfsck -l`
> +RRECOMMENDS_${PN}_append_libc-glibc += "glibc-gconv-ibm437"

I think += should be dropped

> --
> 2.11.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


Re: [OE-core] [PATCH 3/3] libcap-ng: fix built failure with some external toolchains due to missing pthread

2019-11-25 Thread Khem Raj
On Mon, Nov 25, 2019 at 2:13 PM Christopher Larson  wrote:
>
> From: Christopher Larson 
>
> The libcap-ng build doesn't pass -pthread and can fail to link.
>

perhaps, adding a configure time check for pthread.h would be possible

AC_CHECK_HEADERS(pthread.h, [], [AC_MSG_WARN(pthread.h not found,
pthread_atfork disabled.)])

then include pthread.h inside conditional like below in source files.

#ifdef HAVE_PTHREAD_H
#endif



> Signed-off-by: Christopher Larson 
> ---
>  meta/recipes-support/libcap-ng/libcap-ng.inc   |  1 +
>  .../libcap-ng/revert-pthread_atfork-fix.patch  | 56 
> ++
>  2 files changed, 57 insertions(+)
>  create mode 100644 
> meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch
>
> diff --git a/meta/recipes-support/libcap-ng/libcap-ng.inc 
> b/meta/recipes-support/libcap-ng/libcap-ng.inc
> index aec83896e4..46d37e6807 100644
> --- a/meta/recipes-support/libcap-ng/libcap-ng.inc
> +++ b/meta/recipes-support/libcap-ng/libcap-ng.inc
> @@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
>
>  SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
> file://python.patch \
> +   file://revert-pthread_atfork-fix.patch \
>  "
>
>  SRC_URI[md5sum] = "57dc267e2949cdecb651a929f9206572"
> diff --git 
> a/meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch 
> b/meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch
> new file mode 100644
> index 00..d3f7790b1e
> --- /dev/null
> +++ b/meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch
> @@ -0,0 +1,56 @@
> +From 81dc82393fae9851397fa5d94094434aa1d5c3d1 Mon Sep 17 00:00:00 2001
> +From: Christopher Larson 
> +Date: Thu, 14 Nov 2019 21:13:24 +0500
> +Subject: [PATCH] Revert "Fix usage of pthread_atfork a whole different way"
> +
> +This reverts commit 08a09cba90f3d960c080a20833fb8c0908f1cea6.
> +
> +The fix was breaking builds with some toolchains.
> +
> +Signed-off-by: Christopher Larson 
> +---
> + src/Makefile.am |  2 +-
> + src/cap-ng.c| 12 +++-
> + 2 files changed, 12 insertions(+), 2 deletions(-)
> +
> +diff --git a/src/Makefile.am b/src/Makefile.am
> +index 5a66d4e..d46d02b 100644
> +--- a/src/Makefile.am
>  b/src/Makefile.am
> +@@ -34,5 +34,5 @@ noinst_HEADERS = captab.h
> + libcap_ng_la_SOURCES = cap-ng.c lookup_table.c
> + libcap_ng_la_LIBADD =
> + libcap_ng_la_DEPENDENCIES = $(libcap_ng_la_SOURCES) ../config.h
> +-libcap_ng_la_LDFLAGS = -Wl,-z,relro
> ++libcap_ng_la_LDFLAGS = -Wl,-z,relro -Wl,-z,nodelete
> +
> +diff --git a/src/cap-ng.c b/src/cap-ng.c
> +index 35fcd7a..ed31afa 100644
> +--- a/src/cap-ng.c
>  b/src/cap-ng.c
> +@@ -155,6 +155,15 @@ static __thread struct cap_ng m = { 1,
> +   CAPNG_NEW,
> +   {0, 0} };
> +
> ++
> ++/*
> ++ * The pthread_atfork function is being made weak so that we can use it
> ++ * if the program is linked with pthreads and not requiring it for
> ++ * everything that uses libcap-ng.
> ++ */
> ++extern int __attribute__((weak)) pthread_atfork(void (*prepare)(void),
> ++  void (*parent)(void), void (*child)(void));
> ++
> + /*
> +  * Reset the state so that init gets called to erase everything
> +  */
> +@@ -166,7 +175,8 @@ static void deinit(void)
> + static void init_lib(void) __attribute__ ((constructor));
> + static void init_lib(void)
> + {
> +-  pthread_atfork(NULL, NULL, deinit);
> ++  if (pthread_atfork)
> ++  pthread_atfork(NULL, NULL, deinit);
> + }
> +
> + static void init(void)
> --
> 2.11.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 3/3] libcap-ng: fix built failure with some external toolchains due to missing pthread

2019-11-25 Thread Christopher Larson
From: Christopher Larson 

The libcap-ng build doesn't pass -pthread and can fail to link.

Signed-off-by: Christopher Larson 
---
 meta/recipes-support/libcap-ng/libcap-ng.inc   |  1 +
 .../libcap-ng/revert-pthread_atfork-fix.patch  | 56 ++
 2 files changed, 57 insertions(+)
 create mode 100644 
meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch

diff --git a/meta/recipes-support/libcap-ng/libcap-ng.inc 
b/meta/recipes-support/libcap-ng/libcap-ng.inc
index aec83896e4..46d37e6807 100644
--- a/meta/recipes-support/libcap-ng/libcap-ng.inc
+++ b/meta/recipes-support/libcap-ng/libcap-ng.inc
@@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
 SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
file://python.patch \
+   file://revert-pthread_atfork-fix.patch \
 "
 
 SRC_URI[md5sum] = "57dc267e2949cdecb651a929f9206572"
diff --git 
a/meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch 
b/meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch
new file mode 100644
index 00..d3f7790b1e
--- /dev/null
+++ b/meta/recipes-support/libcap-ng/libcap-ng/revert-pthread_atfork-fix.patch
@@ -0,0 +1,56 @@
+From 81dc82393fae9851397fa5d94094434aa1d5c3d1 Mon Sep 17 00:00:00 2001
+From: Christopher Larson 
+Date: Thu, 14 Nov 2019 21:13:24 +0500
+Subject: [PATCH] Revert "Fix usage of pthread_atfork a whole different way"
+
+This reverts commit 08a09cba90f3d960c080a20833fb8c0908f1cea6.
+
+The fix was breaking builds with some toolchains.
+
+Signed-off-by: Christopher Larson 
+---
+ src/Makefile.am |  2 +-
+ src/cap-ng.c| 12 +++-
+ 2 files changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 5a66d4e..d46d02b 100644
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -34,5 +34,5 @@ noinst_HEADERS = captab.h
+ libcap_ng_la_SOURCES = cap-ng.c lookup_table.c
+ libcap_ng_la_LIBADD =
+ libcap_ng_la_DEPENDENCIES = $(libcap_ng_la_SOURCES) ../config.h
+-libcap_ng_la_LDFLAGS = -Wl,-z,relro
++libcap_ng_la_LDFLAGS = -Wl,-z,relro -Wl,-z,nodelete
+ 
+diff --git a/src/cap-ng.c b/src/cap-ng.c
+index 35fcd7a..ed31afa 100644
+--- a/src/cap-ng.c
 b/src/cap-ng.c
+@@ -155,6 +155,15 @@ static __thread struct cap_ng m = { 1,
+   CAPNG_NEW,
+   {0, 0} };
+ 
++
++/*
++ * The pthread_atfork function is being made weak so that we can use it
++ * if the program is linked with pthreads and not requiring it for
++ * everything that uses libcap-ng.
++ */
++extern int __attribute__((weak)) pthread_atfork(void (*prepare)(void),
++  void (*parent)(void), void (*child)(void));
++
+ /*
+  * Reset the state so that init gets called to erase everything
+  */
+@@ -166,7 +175,8 @@ static void deinit(void)
+ static void init_lib(void) __attribute__ ((constructor));
+ static void init_lib(void)
+ {
+-  pthread_atfork(NULL, NULL, deinit);
++  if (pthread_atfork)
++  pthread_atfork(NULL, NULL, deinit);
+ }
+ 
+ static void init(void)
-- 
2.11.1

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


[OE-core] [PATCH 2/3] dosfstools: fix CP437 error from `dosfsck -l`

2019-11-25 Thread Christopher Larson
From: Christopher Larson 

Fix this error seen when using dosfsck -l to list fs contents:

CP437: Invalid argument

Signed-off-by: Christopher Larson 
---
 meta/recipes-devtools/dosfstools/dosfstools_4.1.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb 
b/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
index 69aa81af44..c99d2019c8 100644
--- a/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
+++ b/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
@@ -23,3 +23,6 @@ EXTRA_OECONF = "--without-udev --enable-compat-symlinks"
 CFLAGS += "-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
 
 BBCLASSEXTEND = "native"
+
+# Add codepage437 to avoid error from `dosfsck -l`
+RRECOMMENDS_${PN}_append_libc-glibc += "glibc-gconv-ibm437"
-- 
2.11.1

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


[OE-core] [PATCH 1/3] acpica: correct flex/bison deps, add explicit m4-native dep

2019-11-25 Thread Christopher Larson
From: Christopher Larson 

This project doesn't require target flex or bison, just the natives,
and it uses m4 explicitly in its configuration.

Signed-off-by: Christopher Larson 
---
 meta/recipes-extended/acpica/acpica_20191018.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/acpica/acpica_20191018.bb 
b/meta/recipes-extended/acpica/acpica_20191018.bb
index 4692275762..04732bbfe3 100644
--- a/meta/recipes-extended/acpica/acpica_20191018.bb
+++ b/meta/recipes-extended/acpica/acpica_20191018.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = 
"file://source/compiler/aslcompile.c;beginline=7;endline=150;
 
 COMPATIBLE_HOST = "(i.86|x86_64|arm|aarch64).*-linux"
 
-DEPENDS = "bison flex bison-native"
+DEPENDS = "m4-native flex-native bison-native"
 
 SRC_URI = "https://acpica.org/sites/acpica/files/acpica-unix-${PV}.tar.gz;
 SRC_URI[md5sum] = "539a0252bcb42c383ceeaeb12ae9a60d"
-- 
2.11.1

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


[OE-core] [PATCH] recipes: change SRC_URI to use https

2019-11-25 Thread Stefan Müller-Klieser
Change all recipes to https where we get an http 301 permanent redirect.

Signed-off-by: Stefan Müller-Klieser 
---
 meta/recipes-core/busybox/busybox.inc   | 2 +-
 meta/recipes-core/busybox/busybox_1.31.0.bb | 2 +-
 meta/recipes-core/dbus/dbus-glib_0.110.bb   | 4 ++--
 meta/recipes-core/dbus/dbus_1.12.16.bb  | 4 ++--
 meta/recipes-core/udev/eudev_3.2.8.bb   | 2 +-
 meta/recipes-devtools/patchelf/patchelf_0.10.bb | 2 +-
 meta/recipes-extended/iptables/iptables_1.8.3.bb| 6 +++---
 meta/recipes-extended/libmnl/libmnl_1.0.4.bb| 4 ++--
 meta/recipes-extended/xdg-utils/xdg-utils_1.1.3.bb  | 2 +-
 meta/recipes-extended/xz/xz_5.2.4.bb| 4 ++--
 .../hicolor-icon-theme/hicolor-icon-theme_0.17.bb   | 2 +-
 meta/recipes-kernel/powertop/powertop_2.10.bb   | 6 +++---
 meta/recipes-sato/webkit/webkitgtk_2.26.2.bb| 6 +++---
 meta/recipes-support/db/db_5.3.28.bb| 4 ++--
 meta/recipes-support/libbsd/libbsd_0.10.0.bb| 4 ++--
 meta/recipes-support/libyaml/libyaml_0.2.2.bb   | 4 ++--
 meta/recipes-support/mpfr/mpfr_4.0.2.bb | 4 ++--
 17 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index d08fa8d3d96b..bf6ddae7d197 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -1,6 +1,6 @@
 SUMMARY = "Tiny versions of many common UNIX utilities in a single small 
executable"
 DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities 
into a single small executable. It provides minimalist replacements for most of 
the utilities you usually find in GNU fileutils, shellutils, etc. The utilities 
in BusyBox generally have fewer options than their full-featured GNU cousins; 
however, the options that are included provide the expected functionality and 
behave very much like their GNU counterparts. BusyBox provides a fairly 
complete POSIX environment for any small or embedded system."
-HOMEPAGE = "http://www.busybox.net;
+HOMEPAGE = "https://www.busybox.net;
 BUGTRACKER = "https://bugs.busybox.net/;
 
 DEPENDS += "kern-tools-native virtual/crypt"
diff --git a/meta/recipes-core/busybox/busybox_1.31.0.bb 
b/meta/recipes-core/busybox/busybox_1.31.0.bb
index 34b1f2cc9166..5dd8d448daf6 100644
--- a/meta/recipes-core/busybox/busybox_1.31.0.bb
+++ b/meta/recipes-core/busybox/busybox_1.31.0.bb
@@ -1,6 +1,6 @@
 require busybox.inc
 
-SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball 
\
+SRC_URI = "https://busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-udhcpc-no_deconfig.patch \
file://find-touchscreen.sh \
file://busybox-cron \
diff --git a/meta/recipes-core/dbus/dbus-glib_0.110.bb 
b/meta/recipes-core/dbus/dbus-glib_0.110.bb
index 9afbc2b6a11a..0b45805cf469 100644
--- a/meta/recipes-core/dbus/dbus-glib_0.110.bb
+++ b/meta/recipes-core/dbus/dbus-glib_0.110.bb
@@ -1,7 +1,7 @@
 SUMMARY = "High level language (GLib) binding for D-Bus"
 DESCRIPTION = "GLib bindings for the D-Bus message bus that integrate \
 the D-Bus library with the GLib thread abstraction and main loop."
-HOMEPAGE = "http://www.freedesktop.org/Software/dbus;
+HOMEPAGE = "https://www.freedesktop.org/Software/dbus;
 LICENSE = "AFL-2.1 | GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=cf5b3a2f7083750d504333114e738656 \
 
file://dbus/dbus-glib.h;beginline=7;endline=21;md5=7755c9d7abccd5dbd25a6a974538bb3c"
@@ -10,7 +10,7 @@ SECTION = "base"
 DEPENDS = "expat glib-2.0 virtual/libintl dbus-glib-native dbus"
 DEPENDS_class-native = "glib-2.0-native dbus-native"
 
-SRC_URI = 
"http://dbus.freedesktop.org/releases/dbus-glib/dbus-glib-${PV}.tar.gz \
+SRC_URI = 
"https://dbus.freedesktop.org/releases/dbus-glib/dbus-glib-${PV}.tar.gz \
file://no-examples.patch \
file://test-install-makefile.patch \
 "
diff --git a/meta/recipes-core/dbus/dbus_1.12.16.bb 
b/meta/recipes-core/dbus/dbus_1.12.16.bb
index 96b503687067..82bb753731d8 100644
--- a/meta/recipes-core/dbus/dbus_1.12.16.bb
+++ b/meta/recipes-core/dbus/dbus_1.12.16.bb
@@ -1,6 +1,6 @@
 SUMMARY = "D-Bus message bus"
 DESCRIPTION = "D-Bus is a message bus system, a simple way for applications to 
talk to one another. In addition to interprocess communication, D-Bus helps 
coordinate process lifecycle; it makes it simple and reliable to code a 
\"single instance\" application or daemon, and to launch applications and 
daemons on demand when their services are needed."
-HOMEPAGE = "http://dbus.freedesktop.org;
+HOMEPAGE = "https://dbus.freedesktop.org;
 SECTION = "base"
 LICENSE = "AFL-2.1 | GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
@@ -12,7 +12,7 @@ 

Re: [OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Adrian Bunk
On Mon, Nov 25, 2019 at 07:26:58PM +, Ross Burton wrote:
> On 25/11/2019 18:37, Ankur Tyagi wrote:
> > Hi,
> > 
> > Based upon "thud" branch, I created core-image-minimal for am335x-evm
> > board and resulting image size is very big(71M)
> 
> If disk size is important then a good first step is to use musl instead of
> glibc:
> 
> TCLIBC = "musl"
>...

musl is mainly useful for tiny systems, a 40 MB partition is such a huge
amount of space that the size of the C library no longer matters much.

The size benefit of replacing glibc with musl is around 2 MB.

A partition with an -Os build of Yocto with glibc+systemd (sic)
is around 9 MB, together with bootloader and kernel this all
fits in a 16 MB flash. Use compression for kernel and root
filesystem and everything fits in a 8 MB flash.

> Ross

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


Re: [OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Ross Burton

On 25/11/2019 20:22, Ankur Tyagi wrote:

# Select external binary prebuilt Arm toolchain
TCMODE = "external-arm"
TCLIBC = "external-arm-toolchain"


FWIW, I don't see what the value in external toolchains actually is. 
You might get better results by simply setting:


TCMODE = "default"
TCLIB = "glibc"

(or TCLIBC="musl" if you want to save even more space)

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


Re: [OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Ross Burton

On 25/11/2019 19:54, Ankur Tyagi wrote:

That could be it.
How can I make sure debug stripping is enabled?


It's on by default.  I'd look at your configuration to see what you've 
done to turn it off...

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


[OE-core] Using timestamps (DATETIME) in PV

2019-11-25 Thread Stefan Agner
Hi,

tl;dr: Afaict, using DATETIME in PV is currently impossible due to
commit 9ca2fad2 ("image: Expand PV to avoid AUTOREV parsing failures").
Do not use DATETIME in PV.


In an effort to use timestamps for development builds we tried to use
DATETIME in the PV variable of an image recipe (basically PV =
"${DATETIME}", although my real use case is a bit more involved, but
this is the part which matters). Unfortunately this lead to basehash
value changed errors:

ERROR: When reparsing
/build/ags/torizon-master/build-colibri-imx7/conf/../../layers/meta-toradex-torizon/recipes-images/images/torizon-core-docker.bb:do_patch,
the basehash value changed from
9d65be87aee58d81c6310c5d4a09e1ab94115074c2076766e5bb87267b6257ed to
3b069c8e23e86f778350cd91f17edd00ac71be5fb95a512b1fd567c31dcab46d. The
metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake torizon-core-docker -cdo_patch -Snone
ERROR: Then:
ERROR: $ bitbake torizon-core-docker -cdo_patch -Sprintdiff

Normally this can be fixed by excluding the variable from the
dependencies like this:

PV[vardepsexclude] += "DATETIME"

However, it did not help in this case. I then did what Richard suggests
in [1] and fired up bitbake-diffsigs using the two hashes from the error
showed. This revealed that it is still PV which is an issue:

NOTE: Starting bitbake server...
basehash changed from
4bf60537ad6dbcf8d54972bd81d51ea49d968600cebb6b198c25f4766ae2d31c to
4897cf911d1a75dcdd7f5cbead00d15fd8e419e9e647d49be4585640c67dd0a4
Variable PV value changed from '20191125160227' to '20191125160240'

I found three issues here.

1. sstate.bbclass sets PV[vardepvalue] = "${PV}" to explicitly evaluate
PV (see [2]). This can be easily fixed by clearing vardepvalue, e.g.
PV[vardepvalue] = "".

However, with this fixed we still see issue in custom image tasks.

2. image.bbclass uses localdata.setVar('PV', d.getVar('PV')) to
basically do the same (see [3]). Unfortunately I found no way to easily
alter this behavior from my layer. Since we make use of custom image
tasks we use IMAGE_CMD_x.

3. I also get "The postinstall intercept hook 'update_udev_hwdb' failed,
details in ...temp/log.do_rootfs", it says "chown: invalid user:
‘root:root’". It seems like a pseudo issue, however PSEUDO_LOCALSTATEDIR
seems to be setup correctly. It seems that PSEUDO_LOCALSTATEDIR has a
slight different timestamp then where the rootfs is located but I am not
sure if that is an issue. Anyways, this problem remains unsolved at this
point.

Maybe 2 could be solved differently such that the behavior can be
controlled from an image?

Especially since PV is part of the WORKDIR (which also seems to cause
the third issue) I am not sure how many more problems along those lines
waiting to be found. I plan to move to a different/custom variable to
accomplish my goal. However, since I did all the research so far I
wanted to post this anyway.

--
Stefan


[1]
https://git.openembedded.org/bitbake/commit/?id=857829048c14338132784326ba98a71f12192db8=master
[2]
https://git.openembedded.org/openembedded-core/commit/?id=918646ca803d56004fb0ab7c21e86cc9cb14513d=master
[3]
https://git.openembedded.org/openembedded-core/commit/?id=9ca2fad2e569597f460e6bcbbd96077c8b8cfce9=master
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Ankur Tyagi
Hi Adrian,

Seems you are correct. My distro is based upon TI's Arago distro which uses
following

# Select external binary prebuilt Arm toolchain
TCMODE = "external-arm"
TCLIBC = "external-arm-toolchain"

And external-arm-toolchain.bb recipe has following
require recipes-core/glibc/glibc-package.inc
INHIBIT_DEFAULT_DEPS = "1"
INHIBIT_PACKAGE_STRIP = "1"
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"

And glibc-package.inc has following
INHIBIT_SYSROOT_STRIP = "1"

I just rebuild by disabling INHIBIT_PACKAGE_STRIP = "1" in
external-arm-toolchain.bb and it reduced image size to 12M

$ ls -al lib/
-rwxr-xr-x  1 ankur ankur  138436 Nov 26 09:08 ld-2.28.so
lrwxrwxrwx  1 ankur ankur  10 Nov 26 09:08 ld-linux-armhf.so.3 ->
ld-2.28.so
-rwxr-xr-x  1 ankur ankur 1246708 Nov 26 09:08 libc.so.6
-rwxr-xr-x  1 ankur ankur9600 Nov 26 09:08 libdl.so.2
-rw-r--r--  1 ankur ankur 132 Nov 26 09:07 libgcc_s.so
-rw-r--r--  1 ankur ankur  124396 Nov 26 09:07 libgcc_s.so.1
-rwxr-xr-x  1 ankur ankur  451932 Nov 26 09:08 libm.so.6
-rwxr-xr-x  1 ankur ankur   67292 Nov 26 09:08 libnsl.so.1
-rwxr-xr-x  1 ankur ankur   26244 Nov 26 09:08 libnss_compat.so.2
-rwxr-xr-x  1 ankur ankur   17812 Nov 26 09:08 libnss_dns.so.2
-rwxr-xr-x  1 ankur ankur   38368 Nov 26 09:08 libnss_files.so.2
-rwxr-xr-x  1 ankur ankur   13708 Nov 26 09:08 libnss_hesiod.so.2
-rwxr-xr-x  1 ankur ankur   92356 Nov 26 09:08 libpthread.so.0

$ ls -al usr/lib
total 2816
drwxr-xr-x  3 ankur ankur4096 Nov 26 09:18 .
drwxr-xr-x 10 ankur ankur4096 Nov 26 09:18 ..
lrwxrwxrwx  1 ankur ankur  15 Nov 26 09:12 libi2c.so.0 ->
libi2c.so.0.1.1
-rwxr-xr-x  1 ankur ankur5292 Nov 26 09:12 libi2c.so.0.1.1
lrwxrwxrwx  1 ankur ankur  16 Nov 26 09:11 libkmod.so.2 ->
libkmod.so.2.3.3
-rwxr-xr-x  1 ankur ankur   46840 Nov 26 09:11 libkmod.so.2.3.3
-rwxr-xr-x  1 ankur ankur 1404888 Nov 26 09:08 libstdc++.so.6
-rwxr-xr-x  1 ankur ankur 1404888 Nov 26 09:08 libstdc++.so.6.0.25
-rw-r--r--  1 ankur ankur2388 Nov 26 09:08 libstdc++.so.6.0.25-gdb.py
Thank you so much for help.

Regards
Ankur

On Tue, Nov 26, 2019 at 8:55 AM Adrian Bunk  wrote:

> On Tue, Nov 26, 2019 at 07:37:48AM +1300, Ankur Tyagi wrote:
> > Hi,
> >
> > Based upon "thud" branch, I created core-image-minimal for am335x-evm
> board
> > and resulting image size is very big (71M)
> >
> > /lib dir is 39M and /usr/lib is 24M.
> >...
> > -rwxr-xr-x  1 ankur ankur *16537400* Nov 26 06:41 libc.so.6
> >...
> > -rwxr-xr-x  1 ankur ankur  *6416640* Nov 26 06:41 libm.so.6
> >...
>
> These sizes are the expected sizes for the libraries with debug symbols.
>
> Are you setting INHIBIT_PACKAGE_DEBUG_SPLIT or something similar that
> prevents stripping of the target filesystem?
>
> > Thanks
> > Ankur
>
> cu
> Adrian
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Adrian Bunk
On Tue, Nov 26, 2019 at 07:37:48AM +1300, Ankur Tyagi wrote:
> Hi,
> 
> Based upon "thud" branch, I created core-image-minimal for am335x-evm board
> and resulting image size is very big (71M)
> 
> /lib dir is 39M and /usr/lib is 24M.
>...
> -rwxr-xr-x  1 ankur ankur *16537400* Nov 26 06:41 libc.so.6
>...
> -rwxr-xr-x  1 ankur ankur  *6416640* Nov 26 06:41 libm.so.6
>...

These sizes are the expected sizes for the libraries with debug symbols.

Are you setting INHIBIT_PACKAGE_DEBUG_SPLIT or something similar that 
prevents stripping of the target filesystem?

> Thanks
> Ankur

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


Re: [OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Ankur Tyagi
That could be it.
How can I make sure debug stripping is enabled?

thanks
Ankur

On Tue, Nov 26, 2019 at 8:49 AM Ross Burton  wrote:

> On 25/11/2019 19:33, Ankur Tyagi wrote:
> > Thanks for the suggestion.
> > But curious why libs are so big now?
>
> The same files on my system:
>
> -rwxr-xr-x root/root   1806504 2019-11-04 21:14 ./lib64/libc-2.30.so
> -rwxr-xr-x root/root113296 2019-11-04 21:14 ./lib64/libpthread-2.30.so
> -rw-r--r-- root/root100248 2019-11-04 21:14 ./lib64/libgcc_s.so.1
>
> Your files are a lot larger, so I suspect that you've somehow turned off
> debug stripping.
>
> Ross
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Ross Burton

On 25/11/2019 19:33, Ankur Tyagi wrote:

Thanks for the suggestion.
But curious why libs are so big now?


The same files on my system:

-rwxr-xr-x root/root   1806504 2019-11-04 21:14 ./lib64/libc-2.30.so
-rwxr-xr-x root/root113296 2019-11-04 21:14 ./lib64/libpthread-2.30.so
-rw-r--r-- root/root100248 2019-11-04 21:14 ./lib64/libgcc_s.so.1

Your files are a lot larger, so I suspect that you've somehow turned off 
debug stripping.


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


Re: [OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Ankur Tyagi
Hi Ross,

Thanks for the suggestion.
But curious why libs are so big now?

Regards
Ankur

On Tue, Nov 26, 2019 at 8:27 AM Ross Burton  wrote:

> On 25/11/2019 18:37, Ankur Tyagi wrote:
> > Hi,
> >
> > Based upon "thud" branch, I created core-image-minimal for am335x-evm
> > board and resulting image size is very big(71M)
>
> If disk size is important then a good first step is to use musl instead
> of glibc:
>
> TCLIBC = "musl"
>
> The C++ runtime is also giant, so see if you can not use C++?
>
> Ross
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Ross Burton

On 25/11/2019 18:37, Ankur Tyagi wrote:

Hi,

Based upon "thud" branch, I created core-image-minimal for am335x-evm 
board and resulting image size is very big(71M)


If disk size is important then a good first step is to use musl instead 
of glibc:


TCLIBC = "musl"

The C++ runtime is also giant, so see if you can not use C++?

Ross

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


[OE-core] Very large size of libraries in core-image-minimal rootfs

2019-11-25 Thread Ankur Tyagi
Hi,

Based upon "thud" branch, I created core-image-minimal for am335x-evm board
and resulting image size is very big (71M)

/lib dir is 39M and /usr/lib is 24M.

How can the libraries be trimmed down to fit image inside 40M partition? I
can see duplicacy in /usr/lib and symlink should help but that would reduce
12M. I need to reduce further 20M.

When I was using "daisy" branch, resulting image was much tiny but world
has changed since then. Any help is much appreciated as I am now blocked
and looking for some help.

$ ls -al lib/
total 38712
drwxr-xr-x  4 ankur ankur 4096 Nov 26 07:13 .
drwxr-xr-x 17 ankur ankur 4096 Nov 26 07:13 ..
-rwxr-xr-x  1 ankur ankur  1347940 Nov 26 06:41 ld-2.28.so
lrwxrwxrwx  1 ankur ankur   10 Nov 26 06:41 ld-linux-armhf.so.3 ->
ld-2.28.so
-rwxr-xr-x  1 ankur ankur   133528 Nov 26 06:41 libanl.so.1
lrwxrwxrwx  1 ankur ankur   16 Nov 26 06:41 libattr.so.1 ->
libattr.so.1.1.0
-rw-r--r--  1 ankur ankur13736 Nov 26 06:41 libattr.so.1.1.0
lrwxrwxrwx  1 ankur ankur   17 Nov 26 06:44 libblkid.so.1 ->
libblkid.so.1.1.0
-rwxr-xr-x  1 ankur ankur   195404 Nov 26 06:44 libblkid.so.1.1.0
-rwxr-xr-x  1 ankur ankur25392 Nov 26 06:41 libBrokenLocale.so.1
-rwxr-xr-x  1 ankur ankur   153372 Nov 26 06:41 libcrypt.so.1
-rwxr-xr-x  1 ankur ankur *16537400* Nov 26 06:41 libc.so.6
-rwxr-xr-x  1 ankur ankur   225508 Nov 26 06:41 libdl.so.2
-rw-r--r--  1 ankur ankur  132 Nov 26 06:40 libgcc_s.so
-rw-r--r--  1 ankur ankur  *9063520* Nov 26 06:40 libgcc_s.so.1
-rwxr-xr-x  1 ankur ankur  *6416640* Nov 26 06:41 libm.so.6
-rwxr-xr-x  1 ankur ankur   722176 Nov 26 06:41 libnsl.so.1
-rwxr-xr-x  1 ankur ankur   178932 Nov 26 06:41 libnss_compat.so.2
-rwxr-xr-x  1 ankur ankur   122236 Nov 26 06:41 libnss_dns.so.2
-rwxr-xr-x  1 ankur ankur   373084 Nov 26 06:41 libnss_files.so.2
-rwxr-xr-x  1 ankur ankur   115836 Nov 26 06:41 libnss_hesiod.so.2
lrwxrwxrwx  1 ankur ankur   17 Nov 26 06:44 libpamc.so.0 ->
libpamc.so.0.82.1
-rwxr-xr-x  1 ankur ankur 9592 Nov 26 06:44 libpamc.so.0.82.1
lrwxrwxrwx  1 ankur ankur   21 Nov 26 06:44 libpam_misc.so.0 ->
libpam_misc.so.0.82.1
-rwxr-xr-x  1 ankur ankur 9628 Nov 26 06:44 libpam_misc.so.0.82.1
lrwxrwxrwx  1 ankur ankur   16 Nov 26 06:44 libpam.so.0 ->
libpam.so.0.84.2
-rwxr-xr-x  1 ankur ankur34396 Nov 26 06:44 libpam.so.0.84.2
-rwxr-xr-x  1 ankur ankur  *2742208* Nov 26 06:41 libpthread.so.0
-rwxr-xr-x  1 ankur ankur   436644 Nov 26 06:41 libresolv.so.2
-rwxr-xr-x  1 ankur ankur   424948 Nov 26 06:41 librt.so.1
lrwxrwxrwx  1 ankur ankur   12 Nov 26 06:45 libudev.so.0 -> libudev.so.1
lrwxrwxrwx  1 ankur ankur   16 Nov 26 06:45 libudev.so.1 ->
libudev.so.1.6.3
-rwxr-xr-x  1 ankur ankur88176 Nov 26 06:45 libudev.so.1.6.3
lrwxrwxrwx  1 ankur ankur   19 Nov 26 07:13 libusb-1.0.so.0 ->
libusb-1.0.so.0.1.0
-rwxr-xr-x  1 ankur ankur67292 Nov 26 07:13 libusb-1.0.so.0.1.0
-rwxr-xr-x  1 ankur ankur40320 Nov 26 06:41 libutil.so.1
lrwxrwxrwx  1 ankur ankur   16 Nov 26 06:44 libuuid.so.1 ->
libuuid.so.1.3.0
-rwxr-xr-x  1 ankur ankur22108 Nov 26 06:44 libuuid.so.1.3.0
lrwxrwxrwx  1 ankur ankur   14 Nov 26 06:40 libz.so.1 -> libz.so.1.2.11
-rwxr-xr-x  1 ankur ankur63012 Nov 26 06:40 libz.so.1.2.11
drwxr-xr-x  2 ankur ankur 4096 Nov 26 07:13 security
drwxr-xr-x  3 ankur ankur 4096 Nov 26 06:45 udev

$ ls -al usr/lib/
total 23376
drwxr-xr-x  3 ankur ankur 4096 Nov 26 07:13 .
drwxr-xr-x 10 ankur ankur 4096 Nov 26 07:13 ..
lrwxrwxrwx  1 ankur ankur   15 Nov 26 07:12 libi2c.so.0 ->
libi2c.so.0.1.1
-rwxr-xr-x  1 ankur ankur 5292 Nov 26 07:12 libi2c.so.0.1.1
lrwxrwxrwx  1 ankur ankur   16 Nov 26 06:44 libkmod.so.2 ->
libkmod.so.2.3.3
-rwxr-xr-x  1 ankur ankur46840 Nov 26 06:44 libkmod.so.2.3.3
-rwxr-xr-x  1 ankur ankur *11930116* Nov 26 06:43 libstdc++.so.6
-rwxr-xr-x  1 ankur ankur *11930116* Nov 26 06:43 libstdc++.so.6.0.25
-rw-r--r--  1 ankur ankur 2388 Nov 26 06:43 libstdc++.so.6.0.25-gdb.py
drwxr-xr-x  3 ankur ankur 4096 Nov 26 07:13 opkg

$ du -h
4.0K./sys
4.0K./boot
4.0K./dev
5.5M./sbin
612K./bin
4.0K./usr/share/dict
4.0K./usr/share/man
4.0K./usr/share/misc
4.0K./usr/share/info
20K./usr/share
208K./usr/libexec
824K./usr/sbin
520K./usr/bin
4.0K./usr/include
4.0K./usr/src
4.0K./usr/games
1.1M./usr/lib/opkg/alternatives
1.1M./usr/lib/opkg

*24M./usr/lib26M./usr*
4.0K./var/local
4.0K./var/spool/mail
8.0K./var/spool
4.0K./var/backups
4.0K./var/lib/opkg
4.0K./var/lib/misc
4.0K./var/lib/urandom
16K./var/lib
4.0K./var/volatile
4.0K./var/cache/opkg
8.0K./var/cache/ldconfig
16K./var/cache
56K./var
4.0K./mnt/.psplash
8.0K./mnt
4.0K./proc
4.0K./etc/network/if-up.d
4.0K./etc/network/if-down.d
4.0K./etc/network/if-post-down.d
8.0K./etc/network/if-pre-up.d
28K./etc/network
92K./etc/pam.d
4.0K

Re: [OE-core] [PATCH 2/5] rpm: upgrade to 4.15.1

2019-11-25 Thread Khem Raj
On Mon, Nov 25, 2019 at 8:33 AM Alexander Kanavin
 wrote:
>
> I have reproduced it with gcc and musl. The omp.h is in a non-standard 
> location in recipe-sysroot/usr/lib, which works ok with glibc, but breaks 
> with musl. How gcc is able to find it (or not) is too arcane for my knowledge 
> :(
>
> I added --disable-openmp for musl; the major use for openmp is to speed up 
> native rpm packaging. On target it matters less hopefully.
>
right then lets not make it musl specific rather, disable it for
class-target and keep it on for native alone and may be nativesdk

> Alex
>
> On Mon, 25 Nov 2019 at 16:50, Khem Raj  wrote:
>>
>> On Mon, Nov 25, 2019 at 7:19 AM Alexander Kanavin
>>  wrote:
>> >
>> > omp.h is coming from gcc-runtime. Which compiler are you using? Probably 
>> > an override (specific for that compiler) is needed.
>>
>> if you looked into logs then you must have noticed its clang. I was
>> wonder is openMP a hard dependency
>> for rpm now, which might be interesting for architectures like mips and ppc.
>>
>> >
>> > Alex
>> >
>> > On Sat, 23 Nov 2019 at 18:48, Khem Raj  wrote:
>> >>
>> >> breaks with needing openmp
>> >>
>> >> http://errors.yoctoproject.org/Errors/Details/282827/
>> >>
>> >> perhaps needs explicit dependency on libgomp now ?
>> >>
>> >> On Tue, Nov 19, 2019 at 5:26 AM Alexander Kanavin
>> >>  wrote:
>> >> >
>> >> > Drop patches that were merged upstream.
>> >> >
>> >> > 0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
>> >> > modifies a file that was removed upstream.
>> >> >
>> >> > Add a 0001-rpmfc.c-do-not-run-file-classification-in-parallel.patch
>> >> > as unfortunately the new parallel file classification feature from
>> >> > upstream trips over somewhere in libmagic when inspected files are
>> >> > compressed:
>> >> > https://github.com/rpm-software-management/rpm/issues/756
>> >> >
>> >> > Signed-off-by: Alexander Kanavin 
>> >> > ---
>> >> >  ...satisfiable-dependency-when-building.patch |  28 +-
>> >> >  ...lib-rpm-as-the-installation-path-for.patch |  14 +-
>> >> >  ...kage-building-into-a-separate-functi.patch |  84 -
>> >> >  ...es-requires-do-not-use-monodis-from-.patch |  58 ---
>> >> >  ...-run-file-classification-in-parallel.patch |  65 
>> >> >  ...ry-package-creation-via-thread-pools.patch | 127 ---
>> >> >  ...e-operations-over-string-pools-threa.patch | 207 ---
>> >> >  ...ove-static-local-variables-from-buil.patch | 336 --
>> >> >  .../rpm/{rpm_4.14.2.1.bb => rpm_4.15.1.bb}|  13 +-
>> >> >  9 files changed, 89 insertions(+), 843 deletions(-)
>> >> >  delete mode 100644 
>> >> > meta/recipes-devtools/rpm/files/0001-Split-binary-package-building-into-a-separate-functi.patch
>> >> >  delete mode 100644 
>> >> > meta/recipes-devtools/rpm/files/0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
>> >> >  create mode 100644 
>> >> > meta/recipes-devtools/rpm/files/0001-rpmfc.c-do-not-run-file-classification-in-parallel.patch
>> >> >  delete mode 100644 
>> >> > meta/recipes-devtools/rpm/files/0002-Run-binary-package-creation-via-thread-pools.patch
>> >> >  delete mode 100644 
>> >> > meta/recipes-devtools/rpm/files/0003-rpmstrpool.c-make-operations-over-string-pools-threa.patch
>> >> >  delete mode 100644 
>> >> > meta/recipes-devtools/rpm/files/0004-build-pack.c-remove-static-local-variables-from-buil.patch
>> >> >  rename meta/recipes-devtools/rpm/{rpm_4.14.2.1.bb => rpm_4.15.1.bb} 
>> >> > (91%)
>> >> >
>> >> > diff --git 
>> >> > a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
>> >> >  
>> >> > b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
>> >> > index 80e2f0fad70..4029233fb70 100644
>> >> > --- 
>> >> > a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
>> >> > +++ 
>> >> > b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
>> >> > @@ -1,4 +1,4 @@
>> >> > -From 87cfc0db1ed6fe381a5ed5f0016d8c3344a31a11 Mon Sep 17 00:00:00 2001
>> >> > +From f39c28eb52f12ae6e82db360ffd5a903ac8faca5 Mon Sep 17 00:00:00 2001
>> >> >  From: Alexander Kanavin 
>> >> >  Date: Mon, 9 Jan 2017 18:52:11 +0200
>> >> >  Subject: [PATCH] Do not add an unsatisfiable dependency when building 
>> >> > rpms in
>> >> > @@ -9,25 +9,23 @@ hand produces rpms that way by design.
>> >> >
>> >> >  Upstream-Status: Inappropriate [oe-core specific]
>> >> >  Signed-off-by: Alexander Kanavin 
>> >> > +
>> >> >  ---
>> >> >   build/pack.c | 4 
>> >> >   1 file changed, 4 deletions(-)
>> >> >
>> >> >  diff --git a/build/pack.c b/build/pack.c
>> >> > -index 1261cdbba..bb2d6f4f6 100644
>> >> > +index e6cec1816..810cd7351 100644
>> >> >  --- a/build/pack.c
>> >> >  +++ b/build/pack.c
>> >> > -@@ -595,10 +595,6 @@ rpmRC packageBinaries(rpmSpec spec, const char 
>> >> > *cookie, int cheating)
>> >> > -   headerPutBin(pkg->header, 

[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2019-11-25 Thread sjolley.yp.pm
All,

 

The triage team is starting to try and collect up and classify bugs which a 
newcomer to the project would be able to work on in a way which means people 
can find them. They're being listed on the triage page under the appropriate 
heading:

 

  
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work on 
who doesn't have deep experience with the project.  If anyone can help, please 
take ownership of the bug and send patches!  If anyone needs help/advice there 
are people on irc who can likely do so, or some of the more experienced 
contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs 
reported into the Bugzilla. The number of people attending that meeting has 
fallen, as have the number of people available to help fix bugs. One of the 
things we hear users report is they don't know how to help. We (the triage 
team) are therefore going to start reporting out the currently 295 unassigned 
or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out 
with these.  Bugs are split into two types, "true bugs" where things don't work 
as they should and "enhancements" which are features we'd want to add to the 
system.  There are also roughly four different "priority" classes right now, 
“3.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in 
"3.1" and then “3.2”.

 

Please review this link and if a bug is something you would be able to help 
with either take ownership of the bug, or send me ( 
 sjolley.yp...@gmail.com) an e-mail with the 
bug number you would like and I will assign it to you (please make sure you 
have a Bugzilla account).  The list is at:  
 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs

 

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

7867 SW Bayberry Dr., Beaverton, OR 97007

*Cell:(208) 244-4460

* Email: s  
jolley.yp...@gmail.com  

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


[OE-core] [PATCH 2/5] python-native: don't cause a full regeneration of the built sources

2019-11-25 Thread Alexander Kanavin
From: Ross Burton 

When cross-compiling Python 2 you need a native pgen binary, but the cross
recipe can't do this on it's own so we build it in python-native and install it.

The rule to build pgen was also causing a complete rebuild of all of the
generated sources, which meant that building Python 2 needs a *host* Python 2.

This can be fixed by simply building pgen, as this is all we need to install.

[ YOCTO #13645 ]

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/python/python-native_2.7.17.bb | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-devtools/python/python-native_2.7.17.bb 
b/meta/recipes-devtools/python/python-native_2.7.17.bb
index 936810d9806..98805d998d5 100644
--- a/meta/recipes-devtools/python/python-native_2.7.17.bb
+++ b/meta/recipes-devtools/python/python-native_2.7.17.bb
@@ -35,10 +35,9 @@ do_configure_append() {
autoreconf --verbose --install --force --exclude=autopoint 
../Python-${PV}/Modules/_ctypes/libffi
 }
 
-# Regenerate all of the generated files
-# This ensures that pgen and friends get created during the compile phase
-do_compile_prepend() {
-oe_runmake regen-all
+# Cross-compiling Python needs a native pgen, build it here for use later.
+do_compile_append() {
+   oe_runmake Parser/pgen
 }
 
 do_install() {
-- 
2.17.1

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


[OE-core] [PATCH 5/5] packagegroup-self-hosted: remove python 2.x

2019-11-25 Thread Alexander Kanavin
With this change, python 2.x recipes are ready to be moved to an external layer.
Once that happens, they will be removed from oe-core.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb 
b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
index 0aab23e3e0d..83306caea7c 100644
--- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
@@ -153,8 +153,6 @@ RDEPENDS_packagegroup-self-hosted-extended = "\
 perl-misc \
 perl-modules \
 perl-pod \
-python \
-python-modules \
 python3 \
 python3-modules \
 python3-git \
-- 
2.17.1

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


[OE-core] [PATCH 3/5] python: clean up command overriding

2019-11-25 Thread Alexander Kanavin
From: Ross Burton 

There's no need to add HOSTPGEN or HOSTPYTHON variables when we can just
override the existing PGEN and PYTHON_FOR_BUILD variables.

Signed-off-by: Ross Burton 
---
 .../01-use-proper-tools-for-cross-build.patch | 65 +--
 .../fix_for_using_different_libdir.patch  | 38 ---
 meta/recipes-devtools/python/python_2.7.17.bb |  9 +--
 3 files changed, 20 insertions(+), 92 deletions(-)

diff --git 
a/meta/recipes-devtools/python/python/01-use-proper-tools-for-cross-build.patch 
b/meta/recipes-devtools/python/python/01-use-proper-tools-for-cross-build.patch
index e795a74b911..fa6c5ef1d7f 100644
--- 
a/meta/recipes-devtools/python/python/01-use-proper-tools-for-cross-build.patch
+++ 
b/meta/recipes-devtools/python/python/01-use-proper-tools-for-cross-build.patch
@@ -1,29 +1,13 @@
-We need to ensure our host tools get run during build, not the freshly
-built cross-tools (this will not work), so we introduce HOSTPYTHON and 
HOSTPGEN.
+Unfortunately the explanation for these changes have been lost to the mists of
+time.
 
 Upstream-Status: Inappropriate [embedded specific]
-
-Signed-off-by: Michael 'Mickey' Lauer 
-Signed-off-by: Paul Eggleton 
-
-Rebased for python-2.7.9
-Signed-off-by: Alejandro Hernandez 
-
-Rebased for python-2.7.14
-Signed-off-by: Derek Straka 
+Signed-off-by: Ross Burton 
 
 Index: Python-2.7.13/Makefile.pre.in
 ===
 --- Python-2.7.13.orig/Makefile.pre.in
 +++ Python-2.7.13/Makefile.pre.in
-@@ -245,6 +245,7 @@ LIBFFI_INCLUDEDIR= @LIBFFI_INCLUDEDIR@
- ##
- # Parser
- PGEN= Parser/pgen$(EXE)
-+HOSTPGEN= $(PGEN)$(EXE)
- 
- PSRCS=\
-   Parser/acceler.c \
 @@ -512,7 +513,7 @@ $(BUILDPYTHON):Modules/python.o $(LIBRA
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
  
@@ -33,49 +17,6 @@ Index: Python-2.7.13/Makefile.pre.in
  
  # Create build directory and generate the sysconfig build-time data there.
  # pybuilddir.txt contains the name of the build dir and is used for
-@@ -663,7 +663,7 @@
-   # Regenerate Include/graminit.h and Python/graminit.c
-   # from Grammar/Grammar using pgen
-   @$(MKDIR_P) Include
--  $(PGEN) $(srcdir)/Grammar/Grammar \
-+  $(HOSTPGEN) $(srcdir)/Grammar/Grammar \
-   $(srcdir)/Include/graminit.h \
-   $(srcdir)/Python/graminit.c
- 
-@@ -1121,27 +1122,27 @@ libinstall:build_all $(srcdir)/Lib/$(PL
-   $(DESTDIR)$(LIBDEST)/distutils/tests ; \
-   fi
-   PYTHONPATH=$(DESTDIR)$(LIBDEST)  $(RUNSHARED) \
--  $(PYTHON_FOR_BUILD) -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \
-+  $(HOSTPYTHON) -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \
-   -d $(LIBDEST) -f \
-   -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
-   $(DESTDIR)$(LIBDEST)
-   PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \
--  $(PYTHON_FOR_BUILD) -Wi -tt -O 
$(DESTDIR)$(LIBDEST)/compileall.py \
-+  $(HOSTPYTHON) -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \
-   -d $(LIBDEST) -f \
-   -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
-   $(DESTDIR)$(LIBDEST)
-   -PYTHONPATH=$(DESTDIR)$(LIBDEST)  $(RUNSHARED) \
--  $(PYTHON_FOR_BUILD) -Wi -t $(DESTDIR)$(LIBDEST)/compileall.py \
-+  $(HOSTPYTHON) -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \
-   -d $(LIBDEST)/site-packages -f \
-   -x badsyntax $(DESTDIR)$(LIBDEST)/site-packages
-   -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \
--  $(PYTHON_FOR_BUILD) -Wi -t -O 
$(DESTDIR)$(LIBDEST)/compileall.py \
-+  $(HOSTPYTHON) -Wi -tt $(DESTDIR)$(LIBDEST)/compileall.py \
-   -d $(LIBDEST)/site-packages -f \
-   -x badsyntax $(DESTDIR)$(LIBDEST)/site-packages
-   -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \
--  $(PYTHON_FOR_BUILD) -m lib2to3.pgen2.driver 
$(DESTDIR)$(LIBDEST)/lib2to3/Grammar.txt
-+  $(HOSTPYTHON) -m lib2to3.pgen2.driver 
$(DESTDIR)$(LIBDEST)/lib2to3/Grammar.txt
-   -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \
--  $(PYTHON_FOR_BUILD) -m lib2to3.pgen2.driver 
$(DESTDIR)$(LIBDEST)/lib2to3/PatternGrammar.txt
-+  $(HOSTPYTHON) -m lib2to3.pgen2.driver 
$(DESTDIR)$(LIBDEST)/lib2to3/PatternGrammar.txt
- 
- # Create the PLATDIR source directory, if one wasn't distributed..
- $(srcdir)/Lib/$(PLATDIR):
 Index: Python-2.7.13/setup.py
 ===
 --- Python-2.7.13.orig/setup.py
diff --git 
a/meta/recipes-devtools/python/python/fix_for_using_different_libdir.patch 
b/meta/recipes-devtools/python/python/fix_for_using_different_libdir.patch
index 5f7309367c4..eeb6833186e 100644
--- 

[OE-core] [PATCH 4/5] hosttools: no longer check for or provide host python 2 to builds

2019-11-25 Thread Alexander Kanavin
Signed-off-by: Alexander Kanavin 
---
 meta/classes/base.bbclass| 5 -
 meta/conf/bitbake.conf   | 5 ++---
 scripts/oe-buildenv-internal | 7 ---
 3 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 1cea3a22138..ff3fbb28c31 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -138,11 +138,6 @@ def setup_hosttools_dir(dest, toolsvar, d, fatal=True):
 os.symlink(srctool, desttool)
 else:
 notfound.append(tool)
-# Force "python" -> "python2"
-desttool = os.path.join(dest, "python")
-if not os.path.exists(desttool):
-srctool = "python2"
-os.symlink(srctool, desttool)
 
 if notfound and fatal:
 bb.fatal("The following required tools (as specified by HOSTTOOLS) 
appear to be unavailable in PATH, please install them in order to proceed:\n  
%s" % " ".join(notfound))
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 263d8aea4fb..e75bbcece09 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -481,14 +481,13 @@ export PATH
 HOSTTOOLS_DIR = "${TMPDIR}/hosttools"
 
 # Tools needed to run builds with OE-Core
-# python is special cased to point at python2
 HOSTTOOLS += " \
 [ ar as awk basename bash bzip2 cat chgrp chmod chown chrpath cmp comm cp 
cpio \
 cpp cut date dd diff diffstat dirname du echo egrep env expand expr false \
 fgrep file find flock g++ gawk gcc getconf getopt git grep gunzip gzip \
 head hostname iconv id install ld ldd ln ls make makeinfo md5sum mkdir 
mknod \
-mktemp mv nm objcopy objdump od patch perl pod2man pr printf pwd python2 \
-python2.7 python3 ranlib readelf readlink realpath rm rmdir rpcgen sed seq 
sh sha256sum \
+mktemp mv nm objcopy objdump od patch perl pod2man pr printf pwd \
+python3 ranlib readelf readlink realpath rm rmdir rpcgen sed seq sh 
sha256sum \
 sleep sort split stat strings strip tail tar tee test touch tr true uname \
 uniq wc wget which xargs \
 "
diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal
index 96bb0c3dc95..c17cf4da711 100755
--- a/scripts/oe-buildenv-internal
+++ b/scripts/oe-buildenv-internal
@@ -29,13 +29,6 @@ if [ -z "$OE_SKIP_SDK_CHECK" ] && [ -n "$OECORE_SDK_VERSION" 
]; then
 return 1
 fi
 
-py_v27_check=$(python2 -c 'import sys; print sys.version_info >= (2,7,3)')
-if [ "$py_v27_check" != "True" ]; then
-echo >&2 "OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not 
python v3."
-echo >&2 "Please upgrade your python v2."
-fi
-unset py_v27_check
-
 # We potentially have code that doesn't parse correctly with older versions 
 # of Python, and rather than fixing that and being eternally vigilant for 
 # any other new feature use, just check the version here.
-- 
2.17.1

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


[OE-core] [PATCH 1/5] u-boot: update to 2020.01-rc3 pre-release and drop py2 dependencies

2019-11-25 Thread Alexander Kanavin
Signed-off-by: Alexander Kanavin 
---
 meta/recipes-bsp/u-boot/u-boot-common.inc   | 5 -
 ...-boot-fw-utils_2019.10.bb => u-boot-fw-utils_2020.01.bb} | 0
 .../{u-boot-tools_2019.10.bb => u-boot-tools_2020.01.bb}| 0
 meta/recipes-bsp/u-boot/u-boot.inc  | 6 +++---
 .../u-boot/{u-boot_2019.10.bb => u-boot_2020.01.bb} | 0
 5 files changed, 7 insertions(+), 4 deletions(-)
 rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2019.10.bb => 
u-boot-fw-utils_2020.01.bb} (100%)
 rename meta/recipes-bsp/u-boot/{u-boot-tools_2019.10.bb => 
u-boot-tools_2020.01.bb} (100%)
 rename meta/recipes-bsp/u-boot/{u-boot_2019.10.bb => u-boot_2020.01.bb} (100%)

diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc 
b/meta/recipes-bsp/u-boot/u-boot-common.inc
index c3e458e9251..a0f9c41469e 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
@@ -10,9 +10,12 @@ LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = 
"file://Licenses/README;md5=30503fd321432fc713238f582193b78e"
 PE = "1"
 
+# Drop this line when updating to 2020.01 final
+PV = "2020.01~rc3"
+
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = "61ba1244b548463dbfb3c5285b6b22e7c772c5bd"
+SRCREV = "d4a31e8ee5592072d8d5208b3e950cba2d89b6bd"
 
 SRC_URI = "git://git.denx.de/u-boot.git \
   "
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2019.10.bb 
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2020.01.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2019.10.bb
rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2020.01.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2019.10.bb 
b/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-tools_2019.10.bb
rename to meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 9a754fd09b0..55d8b478701 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -7,13 +7,13 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 DEPENDS += "kern-tools-native"
 
-inherit uboot-config uboot-extlinux-config uboot-sign deploy cml1
+inherit uboot-config uboot-extlinux-config uboot-sign deploy cml1 python3native
 
-DEPENDS += "swig-native python-native"
+DEPENDS += "swig-native"
 
 EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc 
${TOOLCHAIN_OPTIONS}" V=1'
 EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"'
-EXTRA_OEMAKE += 'PYTHON2=nativepython STAGING_INCDIR=${STAGING_INCDIR_NATIVE} 
STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}'
+EXTRA_OEMAKE += 'STAGING_INCDIR=${STAGING_INCDIR_NATIVE} 
STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}'
 
 PACKAGECONFIG ??= "openssl"
 # u-boot will compile its own tools during the build, with specific
diff --git a/meta/recipes-bsp/u-boot/u-boot_2019.10.bb 
b/meta/recipes-bsp/u-boot/u-boot_2020.01.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot_2019.10.bb
rename to meta/recipes-bsp/u-boot/u-boot_2020.01.bb
-- 
2.17.1

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


Re: [OE-core] [PATCH 09/11] p11-kit: convert to meson

2019-11-25 Thread Alexander Kanavin
On Sun, 24 Nov 2019 at 00:04, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Wed, 2019-11-20 at 14:44 +0100, Alexander Kanavin wrote:
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  .../p11-kit/p11-kit_0.23.18.1.bb  | 26 +++
> > 
> >  1 file changed, 3 insertions(+), 23 deletions(-)
>
> I think this caused a failure on the autobuilder:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/1268
>

Thanks, will fix and resend.

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


Re: [OE-core] [PATCH 2/5] rpm: upgrade to 4.15.1

2019-11-25 Thread Alexander Kanavin
I have reproduced it with gcc and musl. The omp.h is in a non-standard
location in recipe-sysroot/usr/lib, which works ok with glibc, but breaks
with musl. How gcc is able to find it (or not) is too arcane for my
knowledge :(

I added --disable-openmp for musl; the major use for openmp is to speed up
native rpm packaging. On target it matters less hopefully.

Alex

On Mon, 25 Nov 2019 at 16:50, Khem Raj  wrote:

> On Mon, Nov 25, 2019 at 7:19 AM Alexander Kanavin
>  wrote:
> >
> > omp.h is coming from gcc-runtime. Which compiler are you using? Probably
> an override (specific for that compiler) is needed.
>
> if you looked into logs then you must have noticed its clang. I was
> wonder is openMP a hard dependency
> for rpm now, which might be interesting for architectures like mips and
> ppc.
>
> >
> > Alex
> >
> > On Sat, 23 Nov 2019 at 18:48, Khem Raj  wrote:
> >>
> >> breaks with needing openmp
> >>
> >> http://errors.yoctoproject.org/Errors/Details/282827/
> >>
> >> perhaps needs explicit dependency on libgomp now ?
> >>
> >> On Tue, Nov 19, 2019 at 5:26 AM Alexander Kanavin
> >>  wrote:
> >> >
> >> > Drop patches that were merged upstream.
> >> >
> >> > 0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
> >> > modifies a file that was removed upstream.
> >> >
> >> > Add a 0001-rpmfc.c-do-not-run-file-classification-in-parallel.patch
> >> > as unfortunately the new parallel file classification feature from
> >> > upstream trips over somewhere in libmagic when inspected files are
> >> > compressed:
> >> > https://github.com/rpm-software-management/rpm/issues/756
> >> >
> >> > Signed-off-by: Alexander Kanavin 
> >> > ---
> >> >  ...satisfiable-dependency-when-building.patch |  28 +-
> >> >  ...lib-rpm-as-the-installation-path-for.patch |  14 +-
> >> >  ...kage-building-into-a-separate-functi.patch |  84 -
> >> >  ...es-requires-do-not-use-monodis-from-.patch |  58 ---
> >> >  ...-run-file-classification-in-parallel.patch |  65 
> >> >  ...ry-package-creation-via-thread-pools.patch | 127 ---
> >> >  ...e-operations-over-string-pools-threa.patch | 207 ---
> >> >  ...ove-static-local-variables-from-buil.patch | 336
> --
> >> >  .../rpm/{rpm_4.14.2.1.bb => rpm_4.15.1.bb}|  13 +-
> >> >  9 files changed, 89 insertions(+), 843 deletions(-)
> >> >  delete mode 100644
> meta/recipes-devtools/rpm/files/0001-Split-binary-package-building-into-a-separate-functi.patch
> >> >  delete mode 100644
> meta/recipes-devtools/rpm/files/0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
> >> >  create mode 100644
> meta/recipes-devtools/rpm/files/0001-rpmfc.c-do-not-run-file-classification-in-parallel.patch
> >> >  delete mode 100644
> meta/recipes-devtools/rpm/files/0002-Run-binary-package-creation-via-thread-pools.patch
> >> >  delete mode 100644
> meta/recipes-devtools/rpm/files/0003-rpmstrpool.c-make-operations-over-string-pools-threa.patch
> >> >  delete mode 100644
> meta/recipes-devtools/rpm/files/0004-build-pack.c-remove-static-local-variables-from-buil.patch
> >> >  rename meta/recipes-devtools/rpm/{rpm_4.14.2.1.bb => rpm_4.15.1.bb}
> (91%)
> >> >
> >> > diff --git
> a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> >> > index 80e2f0fad70..4029233fb70 100644
> >> > ---
> a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> >> > +++
> b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> >> > @@ -1,4 +1,4 @@
> >> > -From 87cfc0db1ed6fe381a5ed5f0016d8c3344a31a11 Mon Sep 17 00:00:00
> 2001
> >> > +From f39c28eb52f12ae6e82db360ffd5a903ac8faca5 Mon Sep 17 00:00:00
> 2001
> >> >  From: Alexander Kanavin 
> >> >  Date: Mon, 9 Jan 2017 18:52:11 +0200
> >> >  Subject: [PATCH] Do not add an unsatisfiable dependency when
> building rpms in
> >> > @@ -9,25 +9,23 @@ hand produces rpms that way by design.
> >> >
> >> >  Upstream-Status: Inappropriate [oe-core specific]
> >> >  Signed-off-by: Alexander Kanavin 
> >> > +
> >> >  ---
> >> >   build/pack.c | 4 
> >> >   1 file changed, 4 deletions(-)
> >> >
> >> >  diff --git a/build/pack.c b/build/pack.c
> >> > -index 1261cdbba..bb2d6f4f6 100644
> >> > +index e6cec1816..810cd7351 100644
> >> >  --- a/build/pack.c
> >> >  +++ b/build/pack.c
> >> > -@@ -595,10 +595,6 @@ rpmRC packageBinaries(rpmSpec spec, const char
> *cookie, int cheating)
> >> > -   headerPutBin(pkg->header, RPMTAG_SOURCEPKGID,
> spec->sourcePkgId,16);
> >> > -   }
> >> > +@@ -724,10 +724,6 @@ static rpmRC packageBinary(rpmSpec spec,
> Package pkg, const char *cookie, int ch
> >> > +   headerPutBin(pkg->header, RPMTAG_SOURCEPKGID,
> spec->sourcePkgId,16);
> >> > + }
> >> > +
> >> > +-if (cheating) {
> >> > +-  (void) rpmlibNeedsFeature(pkg, "ShortCircuited", "4.9.0-1");
> >> > +-   

Re: [OE-core] [PATCH 2/5] rpm: upgrade to 4.15.1

2019-11-25 Thread Khem Raj
On Mon, Nov 25, 2019 at 7:19 AM Alexander Kanavin
 wrote:
>
> omp.h is coming from gcc-runtime. Which compiler are you using? Probably an 
> override (specific for that compiler) is needed.

if you looked into logs then you must have noticed its clang. I was
wonder is openMP a hard dependency
for rpm now, which might be interesting for architectures like mips and ppc.

>
> Alex
>
> On Sat, 23 Nov 2019 at 18:48, Khem Raj  wrote:
>>
>> breaks with needing openmp
>>
>> http://errors.yoctoproject.org/Errors/Details/282827/
>>
>> perhaps needs explicit dependency on libgomp now ?
>>
>> On Tue, Nov 19, 2019 at 5:26 AM Alexander Kanavin
>>  wrote:
>> >
>> > Drop patches that were merged upstream.
>> >
>> > 0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
>> > modifies a file that was removed upstream.
>> >
>> > Add a 0001-rpmfc.c-do-not-run-file-classification-in-parallel.patch
>> > as unfortunately the new parallel file classification feature from
>> > upstream trips over somewhere in libmagic when inspected files are
>> > compressed:
>> > https://github.com/rpm-software-management/rpm/issues/756
>> >
>> > Signed-off-by: Alexander Kanavin 
>> > ---
>> >  ...satisfiable-dependency-when-building.patch |  28 +-
>> >  ...lib-rpm-as-the-installation-path-for.patch |  14 +-
>> >  ...kage-building-into-a-separate-functi.patch |  84 -
>> >  ...es-requires-do-not-use-monodis-from-.patch |  58 ---
>> >  ...-run-file-classification-in-parallel.patch |  65 
>> >  ...ry-package-creation-via-thread-pools.patch | 127 ---
>> >  ...e-operations-over-string-pools-threa.patch | 207 ---
>> >  ...ove-static-local-variables-from-buil.patch | 336 --
>> >  .../rpm/{rpm_4.14.2.1.bb => rpm_4.15.1.bb}|  13 +-
>> >  9 files changed, 89 insertions(+), 843 deletions(-)
>> >  delete mode 100644 
>> > meta/recipes-devtools/rpm/files/0001-Split-binary-package-building-into-a-separate-functi.patch
>> >  delete mode 100644 
>> > meta/recipes-devtools/rpm/files/0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
>> >  create mode 100644 
>> > meta/recipes-devtools/rpm/files/0001-rpmfc.c-do-not-run-file-classification-in-parallel.patch
>> >  delete mode 100644 
>> > meta/recipes-devtools/rpm/files/0002-Run-binary-package-creation-via-thread-pools.patch
>> >  delete mode 100644 
>> > meta/recipes-devtools/rpm/files/0003-rpmstrpool.c-make-operations-over-string-pools-threa.patch
>> >  delete mode 100644 
>> > meta/recipes-devtools/rpm/files/0004-build-pack.c-remove-static-local-variables-from-buil.patch
>> >  rename meta/recipes-devtools/rpm/{rpm_4.14.2.1.bb => rpm_4.15.1.bb} (91%)
>> >
>> > diff --git 
>> > a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
>> >  
>> > b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
>> > index 80e2f0fad70..4029233fb70 100644
>> > --- 
>> > a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
>> > +++ 
>> > b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
>> > @@ -1,4 +1,4 @@
>> > -From 87cfc0db1ed6fe381a5ed5f0016d8c3344a31a11 Mon Sep 17 00:00:00 2001
>> > +From f39c28eb52f12ae6e82db360ffd5a903ac8faca5 Mon Sep 17 00:00:00 2001
>> >  From: Alexander Kanavin 
>> >  Date: Mon, 9 Jan 2017 18:52:11 +0200
>> >  Subject: [PATCH] Do not add an unsatisfiable dependency when building 
>> > rpms in
>> > @@ -9,25 +9,23 @@ hand produces rpms that way by design.
>> >
>> >  Upstream-Status: Inappropriate [oe-core specific]
>> >  Signed-off-by: Alexander Kanavin 
>> > +
>> >  ---
>> >   build/pack.c | 4 
>> >   1 file changed, 4 deletions(-)
>> >
>> >  diff --git a/build/pack.c b/build/pack.c
>> > -index 1261cdbba..bb2d6f4f6 100644
>> > +index e6cec1816..810cd7351 100644
>> >  --- a/build/pack.c
>> >  +++ b/build/pack.c
>> > -@@ -595,10 +595,6 @@ rpmRC packageBinaries(rpmSpec spec, const char 
>> > *cookie, int cheating)
>> > -   headerPutBin(pkg->header, RPMTAG_SOURCEPKGID, 
>> > spec->sourcePkgId,16);
>> > -   }
>> > +@@ -724,10 +724,6 @@ static rpmRC packageBinary(rpmSpec spec, Package 
>> > pkg, const char *cookie, int ch
>> > +   headerPutBin(pkg->header, RPMTAG_SOURCEPKGID, 
>> > spec->sourcePkgId,16);
>> > + }
>> > +
>> > +-if (cheating) {
>> > +-  (void) rpmlibNeedsFeature(pkg, "ShortCircuited", "4.9.0-1");
>> > +-}
>> > +-
>> > + if ((rc = getPkgFilename(pkg->header, filename)))
>> > +   return rc;
>> >
>> > --  if (cheating) {
>> > --  (void) rpmlibNeedsFeature(pkg, "ShortCircuited", "4.9.0-1");
>> > --  }
>> > --
>> > -   {   char *binFormat = rpmGetPath("%{_rpmfilename}", NULL);
>> > -   char *binRpm, *binDir;
>> > -   binRpm = headerFormat(pkg->header, binFormat, );
>> > ---
>> > -2.11.0
>> > -
>> > diff --git 
>> > 

[OE-core] Using kernel device tree when compiling U-Boot

2019-11-25 Thread Mike Crowe via Openembedded-core
I'd like to use a single set of device tree sources for both the kernel and
U-Boot. I'd like to take the dtb files generated when compiling the kernel
and use it for U-Boot. This means that I need to able to find them from the
U-Boot recipe - ideally without having a list of them there.

So, I thought that I'd teach my kernel recipe to install the device trees
in the sysroot. I ought to be able to do this by adding

  SYSROOT_DIRS +="/boot"

to my kernel recipe. Unfortunately, kernel.bbclass contains:

 # We don't need to stage anything, not the modules/firmware since those would 
clash with linux-firmware
 sysroot_stage_all () {
 :
 }

which stops this being effective. This code predates
80e7e7f78d957b8159bede2a5cd5614d8d73039c. Would it now be more appropriate
to influence staging.bbclass's behaviour by setting SYSROOT_DIRS_BLACKLIST
to fix the mentioned clashes? Perhaps the invention of recipe-specific
sysroots might mean that these clashes no longer occur?

The device tree dtb files are published to the deploy directory. I could
try to grab them from there, but even apart from having to deal with the
symlinks, it doesn't feel quite right to do so.

Or perhaps I've missed a much simpler way to solve this problem.

Thanks.

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


Re: [OE-core] [PATCH 2/5] rpm: upgrade to 4.15.1

2019-11-25 Thread Alexander Kanavin
omp.h is coming from gcc-runtime. Which compiler are you using? Probably an
override (specific for that compiler) is needed.

Alex

On Sat, 23 Nov 2019 at 18:48, Khem Raj  wrote:

> breaks with needing openmp
>
> http://errors.yoctoproject.org/Errors/Details/282827/
>
> perhaps needs explicit dependency on libgomp now ?
>
> On Tue, Nov 19, 2019 at 5:26 AM Alexander Kanavin
>  wrote:
> >
> > Drop patches that were merged upstream.
> >
> > 0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
> > modifies a file that was removed upstream.
> >
> > Add a 0001-rpmfc.c-do-not-run-file-classification-in-parallel.patch
> > as unfortunately the new parallel file classification feature from
> > upstream trips over somewhere in libmagic when inspected files are
> > compressed:
> > https://github.com/rpm-software-management/rpm/issues/756
> >
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  ...satisfiable-dependency-when-building.patch |  28 +-
> >  ...lib-rpm-as-the-installation-path-for.patch |  14 +-
> >  ...kage-building-into-a-separate-functi.patch |  84 -
> >  ...es-requires-do-not-use-monodis-from-.patch |  58 ---
> >  ...-run-file-classification-in-parallel.patch |  65 
> >  ...ry-package-creation-via-thread-pools.patch | 127 ---
> >  ...e-operations-over-string-pools-threa.patch | 207 ---
> >  ...ove-static-local-variables-from-buil.patch | 336 --
> >  .../rpm/{rpm_4.14.2.1.bb => rpm_4.15.1.bb}|  13 +-
> >  9 files changed, 89 insertions(+), 843 deletions(-)
> >  delete mode 100644
> meta/recipes-devtools/rpm/files/0001-Split-binary-package-building-into-a-separate-functi.patch
> >  delete mode 100644
> meta/recipes-devtools/rpm/files/0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
> >  create mode 100644
> meta/recipes-devtools/rpm/files/0001-rpmfc.c-do-not-run-file-classification-in-parallel.patch
> >  delete mode 100644
> meta/recipes-devtools/rpm/files/0002-Run-binary-package-creation-via-thread-pools.patch
> >  delete mode 100644
> meta/recipes-devtools/rpm/files/0003-rpmstrpool.c-make-operations-over-string-pools-threa.patch
> >  delete mode 100644
> meta/recipes-devtools/rpm/files/0004-build-pack.c-remove-static-local-variables-from-buil.patch
> >  rename meta/recipes-devtools/rpm/{rpm_4.14.2.1.bb => rpm_4.15.1.bb}
> (91%)
> >
> > diff --git
> a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> > index 80e2f0fad70..4029233fb70 100644
> > ---
> a/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> > +++
> b/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch
> > @@ -1,4 +1,4 @@
> > -From 87cfc0db1ed6fe381a5ed5f0016d8c3344a31a11 Mon Sep 17 00:00:00 2001
> > +From f39c28eb52f12ae6e82db360ffd5a903ac8faca5 Mon Sep 17 00:00:00 2001
> >  From: Alexander Kanavin 
> >  Date: Mon, 9 Jan 2017 18:52:11 +0200
> >  Subject: [PATCH] Do not add an unsatisfiable dependency when building
> rpms in
> > @@ -9,25 +9,23 @@ hand produces rpms that way by design.
> >
> >  Upstream-Status: Inappropriate [oe-core specific]
> >  Signed-off-by: Alexander Kanavin 
> > +
> >  ---
> >   build/pack.c | 4 
> >   1 file changed, 4 deletions(-)
> >
> >  diff --git a/build/pack.c b/build/pack.c
> > -index 1261cdbba..bb2d6f4f6 100644
> > +index e6cec1816..810cd7351 100644
> >  --- a/build/pack.c
> >  +++ b/build/pack.c
> > -@@ -595,10 +595,6 @@ rpmRC packageBinaries(rpmSpec spec, const char
> *cookie, int cheating)
> > -   headerPutBin(pkg->header, RPMTAG_SOURCEPKGID,
> spec->sourcePkgId,16);
> > -   }
> > +@@ -724,10 +724,6 @@ static rpmRC packageBinary(rpmSpec spec, Package
> pkg, const char *cookie, int ch
> > +   headerPutBin(pkg->header, RPMTAG_SOURCEPKGID,
> spec->sourcePkgId,16);
> > + }
> > +
> > +-if (cheating) {
> > +-  (void) rpmlibNeedsFeature(pkg, "ShortCircuited", "4.9.0-1");
> > +-}
> > +-
> > + if ((rc = getPkgFilename(pkg->header, filename)))
> > +   return rc;
> >
> > --  if (cheating) {
> > --  (void) rpmlibNeedsFeature(pkg, "ShortCircuited", "4.9.0-1");
> > --  }
> > --
> > -   {   char *binFormat = rpmGetPath("%{_rpmfilename}", NULL);
> > -   char *binRpm, *binDir;
> > -   binRpm = headerFormat(pkg->header, binFormat, );
> > ---
> > -2.11.0
> > -
> > diff --git
> a/meta/recipes-devtools/rpm/files/0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
> b/meta/recipes-devtools/rpm/files/0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
> > index 82e7328757f..52440d68180 100644
> > ---
> a/meta/recipes-devtools/rpm/files/0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
> > +++
> b/meta/recipes-devtools/rpm/files/0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
> > @@ -1,4 +1,4 @@
> > 

Re: [OE-core] [PATCH v3 00/17] NPM refactoring

2019-11-25 Thread Jean-Marie LEMETAYER
Hi Ross,

On Nov 25, 2019, at 2:55 PM, Ross Burton ross.bur...@intel.com wrote:
> On 22/11/2019 11:08, Jean-Marie LEMETAYER wrote:
>> I based my work on the current implementation, but I never thought of
>> refactoring as much. I have however some concerns about the management
>> of the registry and the development dependencies. I will try to come
>> back with a v4.
> 
> There's a lot of NPM patches flying around now: are any of the patches
> in this 17-long series able to be merged ahead of a full refactor?

No every patches are more or less linked. Moreover Richard points me
some possible enhancements. I will come back with a v4.

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


Re: [OE-core] Oe-core: python and BBCLASSEXTEND = "native nativesdk"

2019-11-25 Thread Ross Burton

On 19/11/2019 15:21, nick83ola wrote:

Dear Openembedded developer,

a lot of python recipes need to add the

BBCLASSEXTEND = "native nativesdk"

To the recipe to build the native version of the package.
Wouldn't be better to add it to the pythonnative.bbclass by default?


No.

pythonnative.bbclass means "I build-depend on python-native and would 
like that python to be on $PATH before the host python".


None of that is relevant to whether a recipe can be built for native or 
nativesdk.


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


Re: [OE-core] [PATCH v3 08/17] npm.bbclass: split the do_compile task

2019-11-25 Thread Ross Burton

On 20/11/2019 09:33, Jean-Marie LEMETAYER wrote:

+python do_fetch_append() {
+"""
+Fetch all dependencies tarball to DL_DIR.
+"""
+bb.fetch2.npm.fetch_dependencies(d)
+}
+
+python do_unpack_append() {
+"""
+Unpack all dependencies tarball to the 'node_modules' directory and add
+them to the npm cache. The dependencies needs to be unpacked to have
+access to the licenses files checksum feature (LIC_FILES_CHKSUM). They
+also have to be in the cache to properly execute the 'npm install'.
+"""
+bb.fetch2.npm.unpack_dependencies(d)
+}


I'd say that appends are a little ugly for introduction of core 
behaviour, maybe using do_fetch[postfuncs] would be neater.


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


Re: [OE-core] [PATCH v3 00/17] NPM refactoring

2019-11-25 Thread Ross Burton

On 22/11/2019 11:08, Jean-Marie LEMETAYER wrote:

I based my work on the current implementation, but I never thought of
refactoring as much. I have however some concerns about the management
of the registry and the development dependencies. I will try to come
back with a v4.


There's a lot of NPM patches flying around now: are any of the patches 
in this 17-long series able to be merged ahead of a full refactor?


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


Re: [OE-core] [PATCH 08/11] lrzsz: remove the recipe

2019-11-25 Thread Ross Burton

On 21/11/2019 13:59, Phil Blundell wrote:

I also have at least a passing fondness for lrzsz and if a small amount
of maintenance now will suffice to keep it working for another 21 years
then I think I would consider that a good outcome.  I will have a quick
look at the code and see if I can fix whatever is apparently problematic
about it.


If you can send a patch sooner rather than later for lrzsz to fix the 
build with modern gettext then that would be *awesome*, as this recipe 
is the sole blocker.


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


[OE-core] [PATCH 4/4] texi2html: remove

2019-11-25 Thread Ross Burton
The last user of this obsolete recipe (abandoned upstream in 2010, removed from
oe-core build dependencies in 2012) has now been deleted from oe-core, so delete
the recipe too.

Signed-off-by: Ross Burton 
---
 meta/conf/distro/include/maintainers.inc  |  1 -
 .../0001-Allow-compiling-out-of-source.patch  | 39 ---
 .../texi2html/texi2html_5.0.bb| 31 ---
 3 files changed, 71 deletions(-)
 delete mode 100644 
meta/recipes-extended/texi2html/files/0001-Allow-compiling-out-of-source.patch
 delete mode 100644 meta/recipes-extended/texi2html/texi2html_5.0.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index a289008b8c1..79404dfbdb7 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -677,7 +677,6 @@ RECIPE_MAINTAINER_pn-tcf-agent = "Anuj Mittal 
"
 RECIPE_MAINTAINER_pn-tcl = "Yi Zhao "
 RECIPE_MAINTAINER_pn-tcp-wrappers = "Robert Yang "
 RECIPE_MAINTAINER_pn-testexport-tarball = "Richard Purdie 
"
-RECIPE_MAINTAINER_pn-texi2html = "Robert Yang "
 RECIPE_MAINTAINER_pn-texinfo = "Anuj Mittal "
 RECIPE_MAINTAINER_pn-texinfo-dummy-native = "Anuj Mittal 
"
 RECIPE_MAINTAINER_pn-tiff = "Alexander Kanavin "
diff --git 
a/meta/recipes-extended/texi2html/files/0001-Allow-compiling-out-of-source.patch
 
b/meta/recipes-extended/texi2html/files/0001-Allow-compiling-out-of-source.patch
deleted file mode 100644
index 0cf025ff4a5..000
--- 
a/meta/recipes-extended/texi2html/files/0001-Allow-compiling-out-of-source.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-From: Olaf Mandel 
-Date: Fri, 21 Oct 2016 13:04:44 +
-Subject: [PATCH] Allow compiling out-of-source
-
-Upstream-Status: Backport of [svn://svn.sv.gnu.org/texinfo/trunk r3602]

- Makefile.am | 2 +-
- Makefile.in | 2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/Makefile.am b/Makefile.am
-index 3447463..c9b5b5c 100644
 a/Makefile.am
-+++ b/Makefile.am
-@@ -208,7 +208,7 @@ i18n/en.thl i18n/: 
$(po_document_dir)/po_document/$(PACKAGE)_document.pot
- done; \
- msgexec -i $< "$(srcdir)/gettext_to_separated.pl" | 
"$(srcdir)/separated_to_hash.pl" en > i18n/en.thl; \
-   else \
--cp -p i18n_ref/*.thl i18n; \
-+cp -p "$(srcdir)/i18n_ref/"*.thl i18n; \
-   fi
- 
- i18n_ref:
-diff --git a/Makefile.in b/Makefile.in
-index 4264b37..a13f84d 100644
 a/Makefile.in
-+++ b/Makefile.in
-@@ -1126,7 +1126,7 @@ i18n/en.thl i18n/: 
$(po_document_dir)/po_document/$(PACKAGE)_document.pot
- done; \
- msgexec -i $< "$(srcdir)/gettext_to_separated.pl" | 
"$(srcdir)/separated_to_hash.pl" en > i18n/en.thl; \
-   else \
--cp -p i18n_ref/*.thl i18n; \
-+cp -p "$(srcdir)/i18n_ref/"*.thl i18n; \
-   fi
- 
- i18n_ref:
--- 
-2.1.4
-
diff --git a/meta/recipes-extended/texi2html/texi2html_5.0.bb 
b/meta/recipes-extended/texi2html/texi2html_5.0.bb
deleted file mode 100644
index afd125b08fa..000
--- a/meta/recipes-extended/texi2html/texi2html_5.0.bb
+++ /dev/null
@@ -1,31 +0,0 @@
-SUMMARY = "Perl script that converts Texinfo to HTML"
-HOMEPAGE= "http://www.nongnu.org/texi2html/;
-SECTION = "console/utils"
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"
-
-PR = "r2"
-
-SRC_URI = "${SAVANNAH_GNU_MIRROR}/texi2html/${BPN}-${PV}.tar.bz2 \
-   file://0001-Allow-compiling-out-of-source.patch \
-   "
-
-SRC_URI[md5sum] = "f15ac876fcdc8be865b16535f480aa54"
-SRC_URI[sha256sum] = 
"e8a98b0ee20c495a6ab894398a065ef580272dbd5a15b1b19e8bd1bc89d9f9fa"
-
-inherit autotools gettext texinfo
-
-do_configure_prepend() {
-   # autotools_do_configure updates po/Makefile.in.in, we also need
-   # update po_document.
-   cp -f ${STAGING_DATADIR_NATIVE}/gettext/po/Makefile.in.in 
${S}/po_document/
-   cp -f ${STAGING_DATADIR_NATIVE}/gettext/po/Makefile.in.in 
${S}/po_messages/
-}
-
-do_install_append () {
-   sed -i -e '1s,#!.*perl,#! ${USRBINPATH}/env perl,' 
${D}${bindir}/texi2html
-}
-
-FILES_${PN}-doc += "${datadir}/texinfo"
-
-RDEPENDS_${PN} = "perl"
-- 
2.20.1

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


[OE-core] [PATCH 3/4] packagegroup-self-hosted: texi2html isn't a build requirement

2019-11-25 Thread Ross Burton
texi2html isn't a build requirement and hasn't been since 2012 (oe-core
aa1c451).

Signed-off-by: Ross Burton 
---
 meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb 
b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
index 7f40e56a19b..996757f7e13 100644
--- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
@@ -167,7 +167,6 @@ RDEPENDS_packagegroup-self-hosted-extended = "\
 sysstat \
 tar \
 tcl \
-texi2html \
 texinfo \
 unzip \
 usbutils \
-- 
2.20.1

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


[OE-core] [PATCH 1/4] packagegroup-core-sdk: remove intltool

2019-11-25 Thread Ross Burton
Intltool is deprecated these days, as gettext can handle almost everything
intltool could.  Remove it from the SDK packagegroups, if it is needed then the
user can add it explicitly.

Signed-off-by: Ross Burton 
---
 meta/recipes-core/packagegroups/packagegroup-core-sdk.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
index 8854ec4801f..03fa5296c15 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
@@ -16,7 +16,6 @@ RDEPENDS_packagegroup-core-sdk = "\
 coreutils \
 ccache \
 diffutils \
-intltool \
 perl-module-re \
 perl-module-text-wrap \
 findutils \
-- 
2.20.1

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


[OE-core] [PATCH 2/4] packagegroup-core-self-hosted: remove intltool

2019-11-25 Thread Ross Burton
Very little software needs intltool to build, and we don't need it on the host
to build Poky.

Signed-off-by: Ross Burton 
---
 meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb 
b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
index 0aab23e3e0d..7f40e56a19b 100644
--- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
@@ -75,7 +75,6 @@ RDEPENDS_packagegroup-self-hosted-sdk = "\
 g++-symlinks \
 gcc \
 gcc-symlinks \
-intltool \
 ldd \
 less \
 libstdc++ \
-- 
2.20.1

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


[OE-core] [PATCH 3/4] opkg: Trim the text part used for the license file checksum

2019-11-25 Thread Peter Kjellerstedt
This avoids including irrelevant information when calculating the
license checksum.

License-Update: Trim the text part used for the license file checksum
Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-devtools/opkg/opkg_0.4.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/opkg/opkg_0.4.1.bb 
b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
index f0ae8b36bd..00ae9c74c2 100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.1.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
@@ -5,7 +5,7 @@ HOMEPAGE = "http://code.google.com/p/opkg/;
 BUGTRACKER = "http://code.google.com/p/opkg/issues/list;
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
-
file://src/opkg.c;beginline=2;endline=21;md5=90435a519c6ea69ef22e4a88bcc52fa0"
+
file://src/opkg.c;beginline=4;endline=18;md5=9f5a1ad5395378a807d6d591e2f92d25"
 
 DEPENDS = "libarchive"
 
-- 
2.21.0

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


[OE-core] [PATCH 2/4] alsa-utils: Trim the text part used for the license file checksum

2019-11-25 Thread Peter Kjellerstedt
This avoids including irrelevant information when calculating the
license checksum.

License-Update: Trim the text part used for the license file checksum
Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb
index 03b5c8de30..c443d3594d 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb
@@ -4,7 +4,7 @@ BUGTRACKER = 
"http://alsa-project.org/main/index.php/Bug_Tracking;
 SECTION = "console/utils"
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
-
file://alsactl/utils.c;beginline=1;endline=20;md5=2ce7f7b6739487fb72c689d46521f958"
+
file://alsactl/utils.c;beginline=3;endline=18;md5=96cc06a4cebe5eb7975688ffb0e65642"
 DEPENDS = "alsa-lib ncurses libsamplerate0"
 
 PACKAGECONFIG ??= "udev"
-- 
2.21.0

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


[OE-core] [PATCH 1/4] alsa-lib: Trim the text part used for the license file checksum

2019-11-25 Thread Peter Kjellerstedt
This avoids including irrelevant information when calculating the
license checksum.

License-Update: Trim the text part used for the license file checksum
Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-multimedia/alsa/alsa-lib_1.1.9.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.9.bb 
b/meta/recipes-multimedia/alsa/alsa-lib_1.1.9.bb
index 2c63ee7522..ba7e978dbe 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.9.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.9.bb
@@ -4,7 +4,7 @@ BUGTRACKER = 
"http://alsa-project.org/main/index.php/Bug_Tracking;
 SECTION = "libs/multimedia"
 LICENSE = "LGPLv2.1 & GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=a916467b91076e631dd8edb7424769c7 \
-
file://src/socket.c;md5=dd1bc7f44872690224d89c1a9806e495;beginline=1;endline=26 
\
+
file://src/socket.c;md5=285675b45e83f571c6a957fe4ab79c93;beginline=9;endline=24 
\
 "
 
 SRC_URI = "https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2;
-- 
2.21.0

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


[OE-core] [PATCH 4/4] libpng: Remove duplicate license information

2019-11-25 Thread Peter Kjellerstedt
The LICENSE file contains all the license information so there is no
need to also include it from the png.h file (and additionally some
lines were left out from the latter).

License-Update: Remove duplicate license information
Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-multimedia/libpng/libpng_1.6.37.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.37.bb 
b/meta/recipes-multimedia/libpng/libpng_1.6.37.bb
index 2ed87a8437..78f3248d73 100644
--- a/meta/recipes-multimedia/libpng/libpng_1.6.37.bb
+++ b/meta/recipes-multimedia/libpng/libpng_1.6.37.bb
@@ -2,9 +2,7 @@ SUMMARY = "PNG image format decoding library"
 HOMEPAGE = "http://www.libpng.org/;
 SECTION = "libs"
 LICENSE = "Libpng"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=b0085051bf265bac2bfc38bc89f5\
-
file://png.h;endline=144;md5=8acd23d544623816b097e07be0139509\
-"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=b0085051bf265bac2bfc38bc89f5"
 DEPENDS = "zlib"
 
 LIBV = "16"
-- 
2.21.0

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


Re: [OE-core] [PATCH] base-files: set ptmxmode to 666

2019-11-25 Thread Stefan Agner
Hi,

On 2019-11-15 17:09, Stefan Agner wrote:
> From: Stefan Agner 
> 
> Make sure that the (newer) /dev/pts/ptmx is accessible by users. This
> is useful e.g. when running containers which symlink /dev/ptmx to
> /dev/pts/ptmx on start. The default mode (000) does not allow to
> create ptys inside the container.
> 
> Using 666 when symlinking /dev/ptmx is also recommended by the kernel
> documentation when /dev/ptmx is symlinked:
> https://www.kernel.org/doc/Documentation/filesystems/devpts.txt
> 
> Also buildroot uses ptmxmode=0666. The patch introducing the change
> explains related use cases why this is necessary a bit more in depth:
> https://github.com/buildroot/buildroot/commit/8196b299ba12bd6741bf7f4462cad180dab77fb0#diff-2d4604b9e565eb19fa52ce31f282f06c
> 

Any thought about this? From what I can tell it did not make it into
oe-core yet?

--
Stefan


> Signed-off-by: Stefan Agner 
> ---
>  meta/recipes-core/base-files/base-files/fstab | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/base-files/base-files/fstab
> b/meta/recipes-core/base-files/base-files/fstab
> index d79a01602f..70e400f567 100644
> --- a/meta/recipes-core/base-files/base-files/fstab
> +++ b/meta/recipes-core/base-files/base-files/fstab
> @@ -2,7 +2,7 @@
>  
>  /dev/root/auto   defaults  1 
>  1
>  proc /procproc   defaults  0 
>  0
> -devpts   /dev/pts devpts mode=0620,gid=5   0 
>  0
> +devpts   /dev/pts devpts
> mode=0620,ptmxmode=0666,gid=5  0  0
>  tmpfs/run tmpfs 
> mode=0755,nodev,nosuid,strictatime 0  0
>  tmpfs/var/volatiletmpfs  defaults  0 
>  0
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 4/4] gcc-runtime: Package libstdc++.a-gdb.py

2019-11-25 Thread Khem Raj
There is python gdb script for static libstdc++ archives as well
fixes
ERROR: gcc-runtime-9.2.0-r0 do_package: QA Issue: gcc-runtime: 
Files/directories were installed but not shipped in any package:
/usr/lib/libstdc++.a-gdb.py

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/gcc-runtime.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index 2da3c02ef0..437a9df08a 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -179,7 +179,7 @@ RRECOMMENDS_${PN}-dbg = ""
 
 # include python debugging scripts
 FILES_${PN}-dbg += "\
-${libdir}/libstdc++.so.*-gdb.py \
+${libdir}/libstdc++.*-gdb.py \
 ${datadir}/gcc-${BINV}/python/libstdcxx \
 "
 
-- 
2.24.0

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


[OE-core] [PATCH 1/4] mtdev: Fix build when using 64bit time_t on 32bit machines

2019-11-25 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 ...64bit-time_t-for-32bit-architectures.patch | 77 +++
 meta/recipes-graphics/wayland/mtdev_1.1.5.bb  |  4 +-
 2 files changed, 80 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-graphics/wayland/mtdev/0001-adjust-for-64bit-time_t-for-32bit-architectures.patch

diff --git 
a/meta/recipes-graphics/wayland/mtdev/0001-adjust-for-64bit-time_t-for-32bit-architectures.patch
 
b/meta/recipes-graphics/wayland/mtdev/0001-adjust-for-64bit-time_t-for-32bit-architectures.patch
new file mode 100644
index 00..a0cebe5283
--- /dev/null
+++ 
b/meta/recipes-graphics/wayland/mtdev/0001-adjust-for-64bit-time_t-for-32bit-architectures.patch
@@ -0,0 +1,77 @@
+From af75e8ee3d12a493b758421b2feed0351fdcbbf0 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Sat, 23 Nov 2019 13:44:32 -0800
+Subject: [PATCH] adjust for 64bit time_t for 32bit architectures
+
+libc that has support for 32 bit applications to use 64 bit
+time_t supplies __USE_TIME_BITS64 define [1]
+
+[1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
+
+Upstream-Status: Pending
+
+Signed-off-by: Khem Raj 
+---
+ src/core.c|  8 +++-
+ test/mtdev-test.c | 10 --
+ 2 files changed, 15 insertions(+), 3 deletions(-)
+
+diff --git a/src/core.c b/src/core.c
+index 87ef420..0d91c0b 100644
+--- a/src/core.c
 b/src/core.c
+@@ -31,6 +31,11 @@
+ #include "evbuf.h"
+ #include "match.h"
+ 
++#ifndef input_event_sec
++#define input_event_sec time.tv_sec
++#define input_event_usec time.tv_usec
++#endif
++
+ static inline int istouch(const struct mtdev_slot *data,
+ const struct mtdev *dev)
+ {
+@@ -251,7 +256,8 @@ static void push_slot_changes(struct mtdev_state *state,
+   count++;
+   if (!count)
+   return;
+-  ev.time = syn->time;
++  ev.input_event_sec = syn->input_event_sec;
++  ev.input_event_usec = syn->input_event_usec;
+   ev.type = EV_ABS;
+   ev.code = ABS_MT_SLOT;
+   ev.value = slot;
+diff --git a/test/mtdev-test.c b/test/mtdev-test.c
+index 1b3e4f2..773f86a 100644
+--- a/test/mtdev-test.c
 b/test/mtdev-test.c
+@@ -30,9 +30,15 @@
+ #include 
+ #include 
+ #include 
++#include 
++
++#ifndef input_event_sec
++#define input_event_sec time.tv_sec
++#define input_event_usec time.tv_usec
++#endif
+ 
+ /* year-proof millisecond event time */
+-typedef __u64 mstime_t;
++typedef uint64_t mstime_t;
+ 
+ static int use_event(const struct input_event *ev)
+ {
+@@ -47,7 +53,7 @@ static void print_event(const struct input_event *ev)
+ {
+   static const mstime_t ms = 1000;
+   static int slot;
+-  mstime_t evtime = ev->time.tv_usec / ms + ev->time.tv_sec * ms;
++  mstime_t evtime = ev->input_event_usec / ms + ev->input_event_sec * ms;
+   if (ev->type == EV_ABS && ev->code == ABS_MT_SLOT)
+   slot = ev->value;
+   fprintf(stderr, "%012llx %02d %01d %04x %d\n",
+-- 
+2.24.0
+
diff --git a/meta/recipes-graphics/wayland/mtdev_1.1.5.bb 
b/meta/recipes-graphics/wayland/mtdev_1.1.5.bb
index ccd0ebbfce..aa8bb69966 100644
--- a/meta/recipes-graphics/wayland/mtdev_1.1.5.bb
+++ b/meta/recipes-graphics/wayland/mtdev_1.1.5.bb
@@ -11,7 +11,9 @@ SECTION = "libs"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=ea6bd0268bb0fcd6b27698616ceee5d6"
 
-SRC_URI = "http://bitmath.org/code/${BPN}/${BP}.tar.bz2;
+SRC_URI = "http://bitmath.org/code/${BPN}/${BP}.tar.bz2 \
+   file://0001-adjust-for-64bit-time_t-for-32bit-architectures.patch \
+"
 SRC_URI[md5sum] = "52c9610b6002f71d1642dc1a1cca5ec1"
 SRC_URI[sha256sum] = 
"6677d5708a7948840de734d8b4675d5980d4561171c5a8e89e54adf7a13eba7f"
 
-- 
2.24.0

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


[OE-core] [PATCH 2/4] libinput: Fix build when using 64bit time_t on 32bit machines

2019-11-25 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 ...64bit-time_t-for-32bit-architectures.patch | 386 ++
 .../wayland/libinput_1.14.3.bb|   4 +-
 2 files changed, 389 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-graphics/wayland/libinput/0001-adjust-for-64bit-time_t-for-32bit-architectures.patch

diff --git 
a/meta/recipes-graphics/wayland/libinput/0001-adjust-for-64bit-time_t-for-32bit-architectures.patch
 
b/meta/recipes-graphics/wayland/libinput/0001-adjust-for-64bit-time_t-for-32bit-architectures.patch
new file mode 100644
index 00..344e6aaf8f
--- /dev/null
+++ 
b/meta/recipes-graphics/wayland/libinput/0001-adjust-for-64bit-time_t-for-32bit-architectures.patch
@@ -0,0 +1,386 @@
+From ab6ce09bfb669177c90cc5c10155eec44e9fc34b Mon Sep 17 00:00:00 2001
+From: Peter Hutterer 
+Date: Sat, 23 Nov 2019 17:23:56 -0800
+Subject: [PATCH] Adjust for 64bit time_t for 32bit architectures
+
+Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/libinput/libinput/merge_requests/346]
+Signed-off-by: Peter Hutterer 
+---
+ meson.build |  1 +
+ src/evdev-mt-touchpad-buttons.c | 15 ---
+ src/evdev.c |  5 ++-
+ src/util-input-event.h  | 69 +
+ tools/libinput-record.c | 16 +---
+ 5 files changed, 90 insertions(+), 16 deletions(-)
+ create mode 100644 src/util-input-event.h
+
+--- a/meson.build
 b/meson.build
+@@ -220,7 +220,8 @@ endif
+  libinput-util.a 
+ src_libinput_util = [
+   'src/libinput-util.c',
+-  'src/libinput-util.h'
++  'src/libinput-util.h',
++  'src/util-input-event.h'
+ ]
+ libinput_util = static_library('libinput-util',
+  src_libinput_util,
+--- a/src/evdev-mt-touchpad-buttons.c
 b/src/evdev-mt-touchpad-buttons.c
+@@ -30,6 +30,7 @@
+ #include 
+ #include "linux/input.h"
+ 
++#include "util-input-event.h"
+ #include "evdev-mt-touchpad.h"
+ 
+ #define DEFAULT_BUTTON_ENTER_TIMEOUT ms2us(100)
+@@ -1145,14 +1146,12 @@ tp_notify_clickpadbutton(struct tp_dispa
+   if (tp->buttons.trackpoint) {
+   if (is_topbutton) {
+   struct evdev_dispatch *dispatch = 
tp->buttons.trackpoint->dispatch;
+-  struct input_event event;
+-  struct input_event syn_report = {{ 0, 0 }, EV_SYN, 
SYN_REPORT, 0 };
++  struct input_event event, syn_report;
++  int value;
+ 
+-  event.time = us2tv(time);
+-  event.type = EV_KEY;
+-  event.code = button;
+-  event.value = (state == LIBINPUT_BUTTON_STATE_PRESSED) 
? 1 : 0;
+-  syn_report.time = event.time;
++  value = (state == LIBINPUT_BUTTON_STATE_PRESSED) ? 1 : 
0;
++  event = input_event_init(time, EV_KEY, button, value);
++  syn_report = input_event_init(time, EV_SYN, SYN_REPORT, 
0);
+   dispatch->interface->process(dispatch,
+tp->buttons.trackpoint,
+,
+--- a/src/evdev.c
 b/src/evdev.c
+@@ -44,6 +44,7 @@
+ #include "filter.h"
+ #include "libinput-private.h"
+ #include "quirks.h"
++#include "util-input-event.h"
+ 
+ #if HAVE_LIBWACOM
+ #include 
+@@ -859,7 +860,7 @@ evdev_print_event(struct evdev_device *d
+ {
+   static uint32_t offset = 0;
+   static uint32_t last_time = 0;
+-  uint32_t time = us2ms(tv2us(>time));
++  uint32_t time = us2ms(input_event_time(e));
+ 
+   if (offset == 0) {
+   offset = time;
+@@ -891,7 +892,7 @@ static inline void
+ evdev_process_event(struct evdev_device *device, struct input_event *e)
+ {
+   struct evdev_dispatch *dispatch = device->dispatch;
+-  uint64_t time = tv2us(>time);
++  uint64_t time = input_event_time(e);
+ 
+ #if 0
+   evdev_print_event(device, e);
+--- /dev/null
 b/src/util-input-event.h
+@@ -0,0 +1,69 @@
++/*
++ * Copyright © 2019 Red Hat, Inc.
++ *
++ * Permission is hereby granted, free of charge, to any person obtaining a
++ * copy of this software and associated documentation files (the "Software"),
++ * to deal in the Software without restriction, including without limitation
++ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
++ * and/or sell copies of the Software, and to permit persons to whom the
++ * Software is furnished to do so, subject to the following conditions:
++ *
++ * The above copyright notice and this permission notice (including the next
++ * paragraph) shall be included in all copies or substantial portions of the
++ * Software.
++ *
++ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
++ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
++ * 

[OE-core] [PATCH 3/4] xf86-input-synaptics: Fix build on 32bit arches when using 64bit time_t

2019-11-25 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 .../64bit_time_t_support.patch| 51 +++
 .../xorg-driver/xf86-input-synaptics_1.9.1.bb |  2 +
 2 files changed, 53 insertions(+)
 create mode 100644 
meta/recipes-graphics/xorg-driver/xf86-input-synaptics/64bit_time_t_support.patch

diff --git 
a/meta/recipes-graphics/xorg-driver/xf86-input-synaptics/64bit_time_t_support.patch
 
b/meta/recipes-graphics/xorg-driver/xf86-input-synaptics/64bit_time_t_support.patch
new file mode 100644
index 00..4bb7fb3e23
--- /dev/null
+++ 
b/meta/recipes-graphics/xorg-driver/xf86-input-synaptics/64bit_time_t_support.patch
@@ -0,0 +1,51 @@
+This patch avoids using time field of input_event structure which is not 
available
+on 32bit arches supporting 64bit time_t structs, Patch makes it compatible 
with new
+and keeps old input.h implementation functional as well.
+
+See https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+
+--- a/src/eventcomm.c
 b/src/eventcomm.c
+@@ -575,10 +575,12 @@ SynapticsReadEvent(InputInfoPtr pInfo, s
+ ev->type = EV_SYN;
+ ev->code = SYN_REPORT;
+ ev->value = 0;
+-ev->time = last_event_time;
+-} else if (ev->type == EV_SYN)
+-last_event_time = ev->time;
+-
++  ev->input_event_sec = last_event_time.tv_sec;
++  ev->input_event_usec = last_event_time.tv_usec;
++} else if (ev->type == EV_SYN) {
++last_event_time.tv_sec = ev->input_event_sec;
++last_event_time.tv_usec = ev->input_event_usec;
++}
+ return TRUE;
+ }
+ 
+@@ -725,7 +727,7 @@ EventReadHwState(InputInfoPtr pInfo,
+ case SYN_REPORT:
+ hw->numFingers = count_fingers(pInfo, comm);
+ if (proto_data->have_monotonic_clock)
+-hw->millis = 1000 * ev.time.tv_sec + ev.time.tv_usec / 
1000;
++hw->millis = 1000 * ev.input_event_sec + 
ev.input_event_usec / 1000;
+ else
+ hw->millis = GetTimeInMillis();
+ SynapticsCopyHwState(hwRet, hw);
+--- a/src/eventcomm.h
 b/src/eventcomm.h
+@@ -34,6 +34,11 @@
+ #include 
+ #include "synproto.h"
+ 
++#ifndef input_event_sec
++#define input_event_sec time.tv_sec
++#define input_event_usec time.tv_usec
++#endif
++
+ /* for auto-dev: */
+ #define DEV_INPUT_EVENT "/dev/input"
+ #define EVENT_DEV_NAME "event"
diff --git a/meta/recipes-graphics/xorg-driver/xf86-input-synaptics_1.9.1.bb 
b/meta/recipes-graphics/xorg-driver/xf86-input-synaptics_1.9.1.bb
index dc31890f69..388350c96e 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-input-synaptics_1.9.1.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-input-synaptics_1.9.1.bb
@@ -10,6 +10,8 @@ advanced features of the touchpad to become available."
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=55aacd3535a741824955c5eb8f061398"
 
+SRC_URI += "file://64bit_time_t_support.patch"
+
 SRC_URI[md5sum] = "cfb79d3c975151f9bbf30b727c260cb9"
 SRC_URI[sha256sum] = 
"7af83526eff1c76e8b9e1553b34245c203d029028d8044dd9dcf71eef1001576"
 
-- 
2.24.0

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


Re: [OE-core] [PATCH 1/1] oeqa: archiver: Add basic tests for all archiver modes

2019-11-25 Thread Paul Barker
Ping on this, it hasn't been accepted yet but also hasn't had any review.

On Mon, 11 Nov 2019, at 14:16, Paul Barker wrote:
> 6 new test cases are added to cover the various archiver modes
> documented at the top of archiver.bbclass. Each test sets the
> appropriate configuration options, runs the `do_deploy_archives` task
> for the selftest-ed recipe and checks for the presence of the expected
> archive file.
> 
> Signed-off-by: Paul Barker 
> ---
>  meta/lib/oeqa/selftest/cases/archiver.py | 66 
>  1 file changed, 66 insertions(+)
> 
> diff --git a/meta/lib/oeqa/selftest/cases/archiver.py 
> b/meta/lib/oeqa/selftest/cases/archiver.py
> index f8672f8abb..6bd0e06ec4 100644
> --- a/meta/lib/oeqa/selftest/cases/archiver.py
> +++ b/meta/lib/oeqa/selftest/cases/archiver.py
> @@ -129,3 +129,69 @@ class Archiver(OESelftestTestCase):
>  self.write_config(features)
>  
>  bitbake('-n core-image-sato')
> +
> +def _test_archiver_mode(self, mode, target_file_name, 
> extra_config=None):
> +target = "selftest-ed"
> +
> +features = 'INHERIT += "archiver"\n'
> +features +=  'ARCHIVER_MODE[src] = "%s"\n' % (mode)
> +if extra_config:
> +features += extra_config
> +self.write_config(features)
> +
> +bitbake('-c clean %s' % (target))
> +bitbake('-c deploy_archives %s' % (target))
> +
> +bb_vars = get_bb_vars(['DEPLOY_DIR_SRC', 'TARGET_SYS'])
> +glob_str = os.path.join(bb_vars['DEPLOY_DIR_SRC'], 
> bb_vars['TARGET_SYS'], '%s-*' % (target))
> +glob_result = glob.glob(glob_str)
> +self.assertTrue(glob_result, 'Missing archiver directory for 
> %s' % (target))
> +
> +archive_path = os.path.join(glob_result[0], target_file_name)
> +self.assertTrue(os.path.exists(archive_path), 'Missing archive 
> file %s' % (target_file_name))
> +
> +def test_archiver_mode_original(self):
> +"""
> +Test that the archiver works in with `ARCHIVER_MODE[src] = 
> "original"`.
> +"""
> +
> +self._test_archiver_mode('original', 'ed-1.14.1.tar.lz')
> +
> +def test_archiver_mode_patched(self):
> +"""
> +Test that the archiver works in with `ARCHIVER_MODE[src] = 
> "patched"`.
> +"""
> +
> +self._test_archiver_mode('patched', 
> 'selftest-ed-1.14.1-r0-patched.tar.gz')
> +
> +def test_archiver_mode_configured(self):
> +"""
> +Test that the archiver works in with `ARCHIVER_MODE[src] = 
> "configured"`.
> +"""
> +
> +self._test_archiver_mode('configured', 
> 'selftest-ed-1.14.1-r0-configured.tar.gz')
> +
> +def test_archiver_mode_recipe(self):
> +"""
> +Test that the archiver works in with `ARCHIVER_MODE[recipe] = 
> "1"`.
> +"""
> +
> +self._test_archiver_mode('patched', 
> 'selftest-ed-1.14.1-r0-recipe.tar.gz',
> + 'ARCHIVER_MODE[recipe] = "1"\n')
> +
> +def test_archiver_mode_diff(self):
> +"""
> +Test that the archiver works in with `ARCHIVER_MODE[diff] = 
> "1"`.
> +Exclusions controlled by `ARCHIVER_MODE[diff-exclude]` are not 
> yet tested.
> +"""
> +
> +self._test_archiver_mode('patched', 
> 'selftest-ed-1.14.1-r0-diff.gz',
> + 'ARCHIVER_MODE[diff] = "1"\n')
> +
> +def test_archiver_mode_dumpdata(self):
> +"""
> +Test that the archiver works in with `ARCHIVER_MODE[dumpdata] 
> = "1"`.
> +"""
> +
> +self._test_archiver_mode('patched', 
> 'selftest-ed-1.14.1-r0-showdata.dump',
> + 'ARCHIVER_MODE[dumpdata] = "1"\n')
> -- 
> 2.24.0
> 
>

-- 
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core