[OE-core] [PATCH] bind-utils: Install nslookup

[Adrian Bunk]

nslookup was undeprecated 15 years ago,
and installing bind-utils should replace the busybox version.

Signed-off-by: Adrian Bunk 
---
 meta/recipes-connectivity/bind/bind_9.11.5.bb | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-connectivity/bind/bind_9.11.5.bb 
b/meta/recipes-connectivity/bind/bind_9.11.5.bb
index 11990ee27e..67672792b1 100644
--- a/meta/recipes-connectivity/bind/bind_9.11.5.bb
+++ b/meta/recipes-connectivity/bind/bind_9.11.5.bb
@@ -73,8 +73,6 @@ do_install_prepend() {
 
 do_install_append() {
 
-   rm "${D}${bindir}/nslookup"
-   rm "${D}${mandir}/man1/nslookup.1"
rmdir "${D}${localstatedir}/run"
rmdir --ignore-fail-on-non-empty "${D}${localstatedir}"
install -d -o bind "${D}${localstatedir}/cache/bind"
@@ -118,8 +116,12 @@ CONFFILES_${PN} = " \
${sysconfdir}/bind/db.root \
"
 
+ALTERNATIVE_${PN}-utils = "nslookup"
+ALTERNATIVE_LINK_NAME[nslookup] = "${bindir}/nslookup"
+ALTERNATIVE_PRIORITY = "100"
+
 PACKAGE_BEFORE_PN += "${PN}-utils"
-FILES_${PN}-utils = "${bindir}/host ${bindir}/dig ${bindir}/mdig 
${bindir}/nsupdate"
+FILES_${PN}-utils = "${bindir}/host ${bindir}/dig ${bindir}/mdig 
${bindir}/nslookup ${bindir}/nsupdate"
 FILES_${PN}-dev += "${bindir}/isc-config.h"
 FILES_${PN} += "${sbindir}/generate-rndc-key.sh"
 
-- 
2.17.1

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

[OE-core] [PATCH] wpa-supplicant: Remove no longer required hack for libnl

[Adrian Bunk]

Upstream already fixed this properly by using pkg-config.

Signed-off-by: Adrian Bunk 
---
 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.7.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.7.bb 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.7.bb
index 6fc5cf5db7..fe5fa2b82e 100644
--- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.7.bb
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.7.bb
@@ -42,8 +42,6 @@ CONFFILES_${PN} += "${sysconfdir}/wpa_supplicant.conf"
 do_configure () {
${MAKE} -C wpa_supplicant clean
install -m 0755 ${WORKDIR}/defconfig wpa_supplicant/.config
-   echo "CFLAGS +=\"-I${STAGING_INCDIR}/libnl3\"" >> wpa_supplicant/.config
-   echo "DRV_CFLAGS +=\"-I${STAGING_INCDIR}/libnl3\"" >> 
wpa_supplicant/.config

if echo "${PACKAGECONFIG}" | grep -qw "openssl"; then
ssl=openssl
-- 
2.17.1

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

[OE-core] [PATCH 2/2] rng-tools: Make nistbeacon support optional

[Adrian Bunk]

Downloading your randomness directly from the US government
is a rare usecase but adds heavy dependencies.

Make it optional and non-default.

Signed-off-by: Adrian Bunk 
---
 meta/recipes-support/rng-tools/rng-tools_6.6.bb | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-support/rng-tools/rng-tools_6.6.bb 
b/meta/recipes-support/rng-tools/rng-tools_6.6.bb
index d3361ae4e1..6796c9be9e 100644
--- a/meta/recipes-support/rng-tools/rng-tools_6.6.bb
+++ b/meta/recipes-support/rng-tools/rng-tools_6.6.bb
@@ -17,9 +17,7 @@ S = "${WORKDIR}/git"
 
 inherit autotools update-rc.d systemd pkgconfig
 
-DEPENDS = "curl \
-   libxml2 \
-   openssl \
+DEPENDS = " \
sysfsutils \
   "
 
@@ -28,6 +26,7 @@ PACKAGECONFIG_libc-musl = "libargp libjitterentropy"
 PACKAGECONFIG[libargp] = "--with-libargp,--without-libargp,argp-standalone,"
 PACKAGECONFIG[libgcrypt] = "--with-libgcrypt,--without-libgcrypt,libgcrypt,"
 PACKAGECONFIG[libjitterentropy] = 
"--enable-jitterentropy,--disable-jitterentropy,libjitterentropy"
+PACKAGECONFIG[nistbeacon] = "--with-nistbeacon,--without-nistbeacon,curl 
libxml2 openssl"
 
 # Refer autogen.sh in rng-tools
 do_configure_prepend() {
-- 
2.17.1

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

[OE-core] [PATCH 1/2] rng-tools: Don't depend on libgcrypt when the PACKAGECONFIG is disabled

[Adrian Bunk]

PACKAGECONFIG[libgcrypt] already adds it when necessary.

Signed-off-by: Adrian Bunk 
---
 meta/recipes-support/rng-tools/rng-tools_6.6.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-support/rng-tools/rng-tools_6.6.bb 
b/meta/recipes-support/rng-tools/rng-tools_6.6.bb
index 4d91216e32..d3361ae4e1 100644
--- a/meta/recipes-support/rng-tools/rng-tools_6.6.bb
+++ b/meta/recipes-support/rng-tools/rng-tools_6.6.bb
@@ -21,7 +21,6 @@ DEPENDS = "curl \
libxml2 \
openssl \
sysfsutils \
-   libgcrypt \
   "
 
 PACKAGECONFIG ??= "libgcrypt libjitterentropy"
-- 
2.17.1

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

Re: [OE-core] [PATCH] gcc-sanitizers: fix the build with -fno-omit-frame-pointer

[Yu, Mingli]

On 2019年03月06日 13:34, Khem Raj wrote:

On Tue, Mar 5, 2019 at 8:24 PM  wrote:


From: Mingli Yu 

Fix the below build issue for gcc-sanitizers when
both -mthumb and -fno-omit-frame-pointer configured
for arm.
| ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function 
'sanitizer::uptr sanitizer::internal_clone(int (*)(void*), void*, int, void*, 
int*, void*, int*)':
| ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:1540:1: error: 
r7 cannot be used in asm here
}

Reference: https://reviews.llvm.org/D50180

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb 
b/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
index f3c7058..2f89c86 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
@@ -5,3 +5,4 @@ require gcc-sanitizers.inc
  # sanitizer_linux.s:5749: Error: lo register required -- `ldr ip,[sp],#8'
  ARM_INSTRUCTION_SET_armv4 = "arm"
  ARM_INSTRUCTION_SET_armv5 = "arm"
+TARGET_CFLAGS_remove_arm = "${@bb.utils.contains('TUNE_CCARGS', '-mthumb', 
'-fno-omit-frame-pointer', '', d)}"


what target does it happen with ? since we set arm ISA for armv5 and
v4 it must be something else


It is armv7vethf.




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

Re: [OE-core] [PATCH] gcc-sanitizers: fix the build with -fno-omit-frame-pointer

[Khem Raj]

On Tue, Mar 5, 2019 at 8:24 PM  wrote:
>
> From: Mingli Yu 
>
> Fix the below build issue for gcc-sanitizers when
> both -mthumb and -fno-omit-frame-pointer configured
> for arm.
> | ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function 
> 'sanitizer::uptr sanitizer::internal_clone(int (*)(void*), void*, int, void*, 
> int*, void*, int*)':
> | ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:1540:1: error: 
> r7 cannot be used in asm here
> }
>
> Reference: https://reviews.llvm.org/D50180
>
> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb 
> b/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
> index f3c7058..2f89c86 100644
> --- a/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
> +++ b/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
> @@ -5,3 +5,4 @@ require gcc-sanitizers.inc
>  # sanitizer_linux.s:5749: Error: lo register required -- `ldr ip,[sp],#8'
>  ARM_INSTRUCTION_SET_armv4 = "arm"
>  ARM_INSTRUCTION_SET_armv5 = "arm"
> +TARGET_CFLAGS_remove_arm = "${@bb.utils.contains('TUNE_CCARGS', '-mthumb', 
> '-fno-omit-frame-pointer', '', d)}"

what target does it happen with ? since we set arm ISA for armv5 and
v4 it must be something else
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] gcc-sanitizers: fix the build with -fno-omit-frame-pointer

[mingli.yu]

From: Mingli Yu 

Fix the below build issue for gcc-sanitizers when
both -mthumb and -fno-omit-frame-pointer configured
for arm.
| ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function 
'sanitizer::uptr sanitizer::internal_clone(int (*)(void*), void*, int, void*, 
int*, void*, int*)':
| ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:1540:1: error: 
r7 cannot be used in asm here
}

Reference: https://reviews.llvm.org/D50180

Signed-off-by: Mingli Yu 
---
 meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb 
b/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
index f3c7058..2f89c86 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
@@ -5,3 +5,4 @@ require gcc-sanitizers.inc
 # sanitizer_linux.s:5749: Error: lo register required -- `ldr ip,[sp],#8'
 ARM_INSTRUCTION_SET_armv4 = "arm"
 ARM_INSTRUCTION_SET_armv5 = "arm"
+TARGET_CFLAGS_remove_arm = "${@bb.utils.contains('TUNE_CCARGS', '-mthumb', 
'-fno-omit-frame-pointer', '', d)}"
-- 
2.7.4

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

[OE-core] [PATCH] libpam: libpamc is licensed under its own BSD-style licence

[Douglas Royds]

Or alternatively GPL, the same as the top-level Linux-PAM COPYING.

Signed-off-by: Douglas Royds 
---
 meta/recipes-extended/pam/libpam_1.3.0.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/pam/libpam_1.3.0.bb 
b/meta/recipes-extended/pam/libpam_1.3.0.bb
index 5c45460c3a..c124e3bb02 100644
--- a/meta/recipes-extended/pam/libpam_1.3.0.bb
+++ b/meta/recipes-extended/pam/libpam_1.3.0.bb
@@ -7,7 +7,9 @@ SECTION = "base"
 # /etc/pam.d comes from Debian libpam-runtime in 2009-11 (at that time
 # libpam-runtime-1.0.1 is GPLv2+), by openembedded
 LICENSE = "GPLv2+ | BSD"
-LIC_FILES_CHKSUM = "file://COPYING;md5=7eb5c1bf854e8881005d673599ee74d3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=7eb5c1bf854e8881005d673599ee74d3 \
+
file://libpamc/License;md5=a4da476a14c093fdc73be3c3c9ba8fb3 \
+"
 
 SRC_URI = "http://linux-pam.org/library/Linux-PAM-${PV}.tar.bz2 \
file://99_pam \
-- 
2.17.1

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

Re: [OE-core] [PATCH v2] glibc: add ld.so locks in _libc_fork

[Khem Raj]

On Fri, Mar 1, 2019 at 2:51 PM Jonathan Rajotte-Julien
 wrote:
>
> Hi,
>
> One of our customer reported that lttng tracing with python (using the python
> agent) resulted in a hang for their applications on Rocko (and up).
>
> After a bit of investigation, it seems that it is related to the second patch
> [1] of this patch series to be applied top of glibc. I know, we are late to 
> the
> party.
>
> [1] file://0028-Bug-4578-add-ld.so-lock-while-fork.patch
>
> Still, you will understand that by the nature of lttng-ust we depend quite a
> bit on specific behaviours of glibc and try to do our best to comply with it.
>
> When tracing using the lttng python agent, a python thread will end up
> performing a dl_open, acquire the dl_locks* along the way, lttng-ust will
> initialize (library constructor), spawn a listener thread and perform a fork 
> to
> modify our process-wide umask for a shm_open call. Our problem arise at the 
> fork
> moment since the dl_locks_* are already taken by the python thread 
> (performing a
> dl_open). I'll spare you the complete deadlock explanation (ust_lock and all).
>
> We do have a patch (lttng-ust) to move all this code to the thread performing
> the library constructor function. This should solve our issue since dl_locks_*
> are nestable.
>
> Anyhow, I believe that those two patches do not have their place in
> OE-core/yocto base layer. I'm not that familiar with yocto/OE, correct me if
> this is the wrong terminology.
>
> The first patch reference/fix a bug [2] that was flagged as invalid by Andreas
> Schwab (schwab) [Project steward] with, from what I understand, a valid 
> reason.
>
> The second patch refers again to bug [2] and also points to bug [3].
>
> From what I understand [3] could also be invalidated for the same reason as 
> [2]
> based on the reproducer. This bug and its solution were never acknowledged by
> any glibc project steward.
>
> Also, Khem Raj asked to ping the glibc bugzilla to, I think, shakes things a 
> bit

I think we should drop these patches and I have sent a patch for the
same to master, you can post it back to release branches that you
are interested in, these were accepted in hope that there will be some
movement on them but clearly, they have been either rejected or stalled
thanks for reporting the regression and analysis.

> on Sept. 5, 2017. This was never acted upon.
>
> I'm not exactly sure why this was merged. Can one appends to the core recipe? 
> If
> so, why was this merged if a customer could carry this patch in their own
> layer/overlay? This does not seems to be a "backport" from upstream glibc or
> something of this nature.
>
> Thanks,
>
> Cheers
>
> [2] https://www.sourceware.org/bugzilla/show_bug.cgi?id=19282
> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=4578
> [4] https://patchwork.openembedded.org/patch/143663/
>
> > Date: Tue, 5 Sep 2017 12:29:44 +0800
> >
> > The patch in this Bugzilla entry was requested by a customer:
> >   https://sourceware.org/bugzilla/show_bug.cgi?id=4578
> >   https://www.sourceware.org/bugzilla/show_bug.cgi?id=19282
> >
> > If a thread happens to hold dl_load_lock and have r_state set to RT_ADD or
> > RT_DELETE at the time another thread calls fork(), then the child exit code
> > from fork (in nptl/sysdeps/unix/sysv/linux/fork.c in our case) 
> > re-initializes
> > dl_load_lock but does not restore r_state to RT_CONSISTENT. If the child
> > subsequently requires ld.so functionality before calling exec(), then the
> > assertion will fire.
> >
> > The patch acquires dl_load_lock on entry to fork() and releases it on exit
> > from the parent path.  The child path is initialized as currently done.
> > This is essentially pthreads_atfork, but forced to be first because the
> > acquisition of dl_load_lock must happen before malloc_atfork is active
> > to avoid a deadlock.
> >
> > The __libc_fork() code reset dl_load_lock, but it also needed to reset
> > dl_load_write_lock.
> >
> > Signed-off-by: Zhixiong Chi 
> > ---
> >  ...bc-reset-dl-load-write-lock-after-forking.patch | 37 ++
> >  .../0028-Bug-4578-add-ld.so-lock-while-fork.patch  | 57 
> > ++
> >  meta/recipes-core/glibc/glibc_2.26.bb  |  2 +
> >  3 files changed, 96 insertions(+)
> >  create mode 100644 
> > meta/recipes-core/glibc/glibc/0027-glibc-reset-dl-load-write-lock-after-forking.patch
> >  create mode 100644 
> > meta/recipes-core/glibc/glibc/0028-Bug-4578-add-ld.so-lock-while-fork.patch
> >
> > diff --git 
> > a/meta/recipes-core/glibc/glibc/0027-glibc-reset-dl-load-write-lock-after-forking.patch
> >  
> > b/meta/recipes-core/glibc/glibc/0027-glibc-reset-dl-load-write-lock-after-forking.patch
> > new file mode 100644
> > index 000..777b253
> > --- /dev/null
> > +++ 
> > b/meta/recipes-core/glibc/glibc/0027-glibc-reset-dl-load-write-lock-after-forking.patch
> > @@ -0,0 +1,37 @@
> > +From a6bb73d1cfd20a73fbbe6076008376fb87879d1b Mon Sep 17 00:00:00 2001
> > +From: Yuanjie Huang 
> > 

[OE-core] [PATCH] glibc: Drop upstream rejected patches

[Khem Raj]

These patches were applied, hoping that they will eventually be accepted
upstream but they have been rejected, I think its best that they are
dropped so we can avoid novel unintended behaviours that no other
distros will be seeing

Signed-off-by: Khem Raj 
---
 ...set-dl_load_write_lock-after-forking.patch | 40 ---
 ...ck-before-switching-to-malloc_atfork.patch | 68 ---
 meta/recipes-core/glibc/glibc_2.29.bb |  2 -
 3 files changed, 110 deletions(-)
 delete mode 100644 
meta/recipes-core/glibc/glibc/0026-reset-dl_load_write_lock-after-forking.patch
 delete mode 100644 
meta/recipes-core/glibc/glibc/0027-Acquire-ld.so-lock-before-switching-to-malloc_atfork.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0026-reset-dl_load_write_lock-after-forking.patch
 
b/meta/recipes-core/glibc/glibc/0026-reset-dl_load_write_lock-after-forking.patch
deleted file mode 100644
index 70696b8d3c..00
--- 
a/meta/recipes-core/glibc/glibc/0026-reset-dl_load_write_lock-after-forking.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From e6e6e5011611fa22186508a3ff8ed4215a529f1f Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Sat, 27 Jan 2018 10:05:07 -0800
-Subject: [PATCH 26/30] reset dl_load_write_lock after forking
-
-The patch in this Bugzilla entry was requested by a customer:
-
-  https://www.sourceware.org/bugzilla/show_bug.cgi?id=19282
-
-The __libc_fork() code reset dl_load_lock, but it also needed to reset
-dl_load_write_lock.  The patch has not yet been integrated upstream.
-
-Upstream-Status: Pending [ No Author See bugzilla]
-
-Signed-off-by: Damodar Sonone 
-Signed-off-by: Yuanjie Huang 
-Signed-off-by: Khem Raj 

- sysdeps/nptl/fork.c | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/sysdeps/nptl/fork.c b/sysdeps/nptl/fork.c
-index bd68f18b45..5c9bb44372 100644
 a/sysdeps/nptl/fork.c
-+++ b/sysdeps/nptl/fork.c
-@@ -130,9 +130,9 @@ __libc_fork (void)
- _IO_list_resetlock ();
-   }
- 
--  /* Reset the lock the dynamic loader uses to protect its data.  */
-+  /* Reset the locks the dynamic loader uses to protect its data.  */
-   __rtld_lock_initialize (GL(dl_load_lock));
--
-+  __rtld_lock_initialize (GL(dl_load_write_lock));
-   /* Run the handlers registered for the child.  */
-   __run_fork_handlers (atfork_run_child);
- }
--- 
-2.20.1
-
diff --git 
a/meta/recipes-core/glibc/glibc/0027-Acquire-ld.so-lock-before-switching-to-malloc_atfork.patch
 
b/meta/recipes-core/glibc/glibc/0027-Acquire-ld.so-lock-before-switching-to-malloc_atfork.patch
deleted file mode 100644
index 5bc813a900..00
--- 
a/meta/recipes-core/glibc/glibc/0027-Acquire-ld.so-lock-before-switching-to-malloc_atfork.patch
+++ /dev/null
@@ -1,68 +0,0 @@
-From eb43af9afba3c2b499be6e71b69687d4e7c6272a Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Sat, 27 Jan 2018 10:08:04 -0800
-Subject: [PATCH 27/30] Acquire ld.so lock before switching to malloc_atfork
-
-The patch is from
-  https://sourceware.org/bugzilla/show_bug.cgi?id=4578
-
-If a thread happens to hold dl_load_lock and have r_state set to RT_ADD or
-RT_DELETE at the time another thread calls fork(), then the child exit code
-from fork (in nptl/sysdeps/unix/sysv/linux/fork.c in our case) re-initializes
-dl_load_lock but does not restore r_state to RT_CONSISTENT. If the child
-subsequently requires ld.so functionality before calling exec(), then the
-assertion will fire.
-
-The patch acquires dl_load_lock on entry to fork() and releases it on exit
-from the parent path.  The child path is initialized as currently done.
-This is essentially pthreads_atfork, but forced to be first because the
-acquisition of dl_load_lock must happen before malloc_atfork is active
-to avoid a deadlock.
-
-The patch has not yet been integrated upstream.
-
-Upstream-Status: Pending [ Not Author See bugzilla]
-
-Signed-off-by: Raghunath Lolur 
-Signed-off-by: Yuanjie Huang 
-Signed-off-by: Zhixiong Chi 
-Signed-off-by: Khem Raj 

- sysdeps/nptl/fork.c | 7 +++
- 1 file changed, 7 insertions(+)
-
-diff --git a/sysdeps/nptl/fork.c b/sysdeps/nptl/fork.c
-index 5c9bb44372..84a1a404b3 100644
 a/sysdeps/nptl/fork.c
-+++ b/sysdeps/nptl/fork.c
-@@ -25,6 +25,7 @@
- #include 
- #include 
- #include 
-+#include 
- #include 
- #include 
- #include 
-@@ -56,6 +57,9 @@ __libc_fork (void)
-   bool multiple_threads = THREAD_GETMEM (THREAD_SELF, 
header.multiple_threads);
- 
-   __run_fork_handlers (atfork_run_prepare);
-+  /* grab ld.so lock BEFORE switching to malloc_atfork */
-+  __rtld_lock_lock_recursive (GL(dl_load_lock));
-+  __rtld_lock_lock_recursive (GL(dl_load_write_lock));
- 
-   /* If we are not running multiple threads, we do not have to
-  preserve lock state.  If fork runs from a signal handler, only
-@@ -150,6 +154,9 @@ __libc_fork (void)
- 
-   /* Run the handlers registered for the parent.  */
-   __run_fork_handlers (atfork_run_parent);
-+  /* unlock ld.so last, because we locked 

[OE-core] [PATCH] cairo: fix CVE-2018-19876 CVE-2019-6461 CVE-2019-6462

[Ross Burton]

CVE-2018-19876 is a backport from upstream.

CVE-2019-6461 and CVE-2019-6462 are patches taken from Clear Linux.

Signed-off-by: Ross Burton 
---
 .../cairo/cairo/CVE-2018-19876.patch   | 34 ++
 .../cairo/cairo/CVE-2019-6461.patch| 19 
 .../cairo/cairo/CVE-2019-6462.patch| 20 +
 meta/recipes-graphics/cairo/cairo_1.16.0.bb|  3 ++
 4 files changed, 76 insertions(+)
 create mode 100644 meta/recipes-graphics/cairo/cairo/CVE-2018-19876.patch
 create mode 100644 meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
 create mode 100644 meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch

diff --git a/meta/recipes-graphics/cairo/cairo/CVE-2018-19876.patch 
b/meta/recipes-graphics/cairo/cairo/CVE-2018-19876.patch
new file mode 100644
index 000..4252a5663b9
--- /dev/null
+++ b/meta/recipes-graphics/cairo/cairo/CVE-2018-19876.patch
@@ -0,0 +1,34 @@
+CVE: CVE-2018-19876
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From 90e85c2493fdfa3551f202ff10282463f1e36645 Mon Sep 17 00:00:00 2001
+From: Carlos Garcia Campos 
+Date: Mon, 19 Nov 2018 12:33:07 +0100
+Subject: [PATCH] ft: Use FT_Done_MM_Var instead of free when available in
+ cairo_ft_apply_variations
+
+Fixes a crash when using freetype >= 2.9
+---
+ src/cairo-ft-font.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/src/cairo-ft-font.c b/src/cairo-ft-font.c
+index 325dd61b4..981973f78 100644
+--- a/src/cairo-ft-font.c
 b/src/cairo-ft-font.c
+@@ -2393,7 +2393,11 @@ skip:
+ done:
+ free (coords);
+ free (current_coords);
++#if HAVE_FT_DONE_MM_VAR
++FT_Done_MM_Var (face->glyph->library, ft_mm_var);
++#else
+ free (ft_mm_var);
++#endif
+ }
+ }
+ 
+-- 
+2.11.0
+
diff --git a/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch 
b/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
new file mode 100644
index 000..5232cf70c69
--- /dev/null
+++ b/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
@@ -0,0 +1,19 @@
+There is a potential infinite-loop in function _arc_error_normalized().
+
+CVE: CVE-2019-6461
+Upstream-Status: Pending
+Signed-off-by: Ross Burton 
+
+diff --git a/src/cairo-arc.c b/src/cairo-arc.c
+index 390397bae..f9249dbeb 100644
+--- a/src/cairo-arc.c
 b/src/cairo-arc.c
+@@ -99,7 +99,7 @@ _arc_max_angle_for_tolerance_normalized (double tolerance)
+ do {
+   angle = M_PI / i++;
+   error = _arc_error_normalized (angle);
+-} while (error > tolerance);
++} while (error > tolerance && error > __DBL_EPSILON__);
+ 
+ return angle;
+ }
diff --git a/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch 
b/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
new file mode 100644
index 000..4e4598c5b5d
--- /dev/null
+++ b/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
@@ -0,0 +1,20 @@
+There is an assertion in function _cairo_arc_in_direction().
+
+CVE: CVE-2019-6462
+Upstream-Status: Pending
+Signed-off-by: Ross Burton 
+
+diff --git a/src/cairo-arc.c b/src/cairo-arc.c
+index 390397bae..1bde774a4 100644
+--- a/src/cairo-arc.c
 b/src/cairo-arc.c
+@@ -186,7 +186,8 @@ _cairo_arc_in_direction (cairo_t *cr,
+ if (cairo_status (cr))
+ return;
+ 
+-assert (angle_max >= angle_min);
++if (angle_max < angle_min)
++   return;
+ 
+ if (angle_max - angle_min > 2 * M_PI * MAX_FULL_CIRCLES) {
+   angle_max = fmod (angle_max - angle_min, 2 * M_PI);
diff --git a/meta/recipes-graphics/cairo/cairo_1.16.0.bb 
b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
index cdef023198f..c2628ae0ca0 100644
--- a/meta/recipes-graphics/cairo/cairo_1.16.0.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
@@ -24,6 +24,9 @@ DEPENDS = "fontconfig glib-2.0 libpng pixman zlib"
 
 SRC_URI = "http://cairographics.org/releases/cairo-${PV}.tar.xz \
file://cairo-get_bitmap_surface-bsc1036789-CVE-2017-7475.diff \ 
+   file://CVE-2018-19876.patch \
+   file://CVE-2019-6461.patch \
+   file://CVE-2019-6462.patch \
   "
 
 SRC_URI[md5sum] = "f19e0353828269c22bd72e271243a552"
-- 
2.11.0

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

[OE-core] [PATCH] insane.bbclass: fix QA-check to consider the PREFERRED_RPROVIDER for RDEPENDS

[Catalin Dan Udma]

QA-check looks in the RDEPENDS list without taking into consideration that a
specific package may have a PREFERRED_RPROVIDER defined.
If PREFERRED_RPROVIDER is set, QA-check will ignore that settings and will
consider the original package, resulting in QA-check errors:
ERROR: do_packate_qa: QA Issue: <...>, but no providers found in
RDEPENDS_? [file-rdeps]
The fix is to replace the original package in the QA-check with the new
package defined in PREFERRED_RPROVIDER, if it’s set.

Signed-off-by: Catalin Udma 
---
 meta/classes/insane.bbclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 6411884..165233b 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -689,6 +689,9 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, taskdeps, 
packages, d):
 # Now do the sanity check!!!
 if "build-deps" not in skip:
 for rdepend in rdepends:
+pref_rdepend = localdata.getVar("PREFERRED_RPROVIDER_%s" % 
rdepend)
+if pref_rdepend:
+rdepend = pref_rdepend
 if "-dbg" in rdepend and "debug-deps" not in skip:
 error_msg = "%s rdepends on %s" % (pkg,rdepend)
 package_qa_handle_error("debug-deps", error_msg, d)
@@ -739,6 +742,9 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, taskdeps, 
packages, d):
 while next:
 new = []
 for rdep in next:
+pref_rdep = localdata.getVar("PREFERRED_RPROVIDER_%s" 
% rdep)
+if pref_rdep:
+rdep = pref_rdep
 rdep_data = oe.packagedata.read_subpkgdata(rdep, d)
 sub_rdeps = rdep_data.get("RDEPENDS_" + rdep)
 if not sub_rdeps:
-- 
2.7.4

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

[OE-core] [OE-Core][PATCH v2 2/3] qemuarm64: Add graphics support

[Jon Mason]

Add the necessary parts to qemuarm64.conf for graphics to be shown in
the SDL window, and USB so that it is possible to interact with it.

Signed-off-by: Jon Mason 
---
 meta/conf/machine/qemuarm64.conf | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index 43078588a8..e17245a0f7 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -14,9 +14,11 @@ QB_SYSTEM_NAME = "qemu-system-aarch64"
 QB_MEM = "-m 512"
 QB_MACHINE = "-machine virt"
 QB_CPU = "-cpu cortex-a57"
-# Standard Serial console and graphics (or lack thereof in this instance)
+# Standard Serial console
 QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0"
-QB_OPT_APPEND = "-show-cursor -monitor null"
+# For graphics to work we need to define the VGA device as well as the 
necessary USB devices
+QB_OPT_APPEND = "-show-cursor -device VGA"
+QB_OPT_APPEND += "-device qemu-xhci -device usb-tablet -device usb-kbd"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
 # Virtio Networking support
@@ -27,3 +29,5 @@ QB_ROOTFS_OPT = "-drive 
id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio
 # Virtio serial console
 QB_SERIAL_OPT = "-device virtio-serial-device -chardev null,id=virtcon -device 
virtconsole,chardev=virtcon"
 QB_TCPSERIAL_OPT = "-device virtio-serial-device -chardev 
socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device 
virtconsole,chardev=virtcon"
+
+PREFERRED_VERSION_linux-yocto ?= "4.19%"
-- 
2.17.2

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

[OE-core] [OE-Core][PATCH v2 3/3] qemuarma15: ARM A15 Support

[Jon Mason]

Add new QEMU BSP for a Arm Cortex-A15 system.  This uses the QEMU virt
machine type, which should be faster to emulate.

Signed-off-by: Jon Mason 
---
 meta/conf/machine/qemuarma15.conf | 33 +++
 .../linux/linux-yocto-rt_4.19.bb  |  2 +-
 .../linux/linux-yocto-tiny_4.19.bb|  2 +-
 meta/recipes-kernel/linux/linux-yocto_4.19.bb |  2 +-
 4 files changed, 36 insertions(+), 3 deletions(-)
 create mode 100644 meta/conf/machine/qemuarma15.conf

diff --git a/meta/conf/machine/qemuarma15.conf 
b/meta/conf/machine/qemuarma15.conf
new file mode 100644
index 00..f8ab9d5538
--- /dev/null
+++ b/meta/conf/machine/qemuarma15.conf
@@ -0,0 +1,33 @@
+#@TYPE: Machine
+#@NAME: generic Arm Cortex-A15 machine
+#@DESCRIPTION: Machine configuration for running a generic armv7
+
+require conf/machine/include/tune-cortexa15.inc
+require conf/machine/include/qemu.inc
+
+KERNEL_IMAGETYPE = "zImage"
+
+SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
+
+# For runqemu
+QB_SYSTEM_NAME = "qemu-system-arm"
+QB_MEM = "-m 512"
+QB_MACHINE = "-machine virt"
+QB_CPU = "-cpu cortex-a15"
+# Standard Serial console
+QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0"
+# For graphics to work we need to define the VGA device as well as the 
necessary USB devices
+QB_OPT_APPEND = "-show-cursor -device VGA"
+QB_OPT_APPEND += "-device qemu-xhci -device usb-tablet -device usb-kbd"
+# Add the virtio RNG
+QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
+# Virtio Networking support
+QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
+QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
+# Virtio block device
+QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device 
virtio-blk-device,drive=disk0"
+# Virtio serial console
+QB_SERIAL_OPT = "-device virtio-serial-device -chardev null,id=virtcon -device 
virtconsole,chardev=virtcon"
+QB_TCPSERIAL_OPT = "-device virtio-serial-device -chardev 
socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device 
virtconsole,chardev=virtcon"
+
+PREFERRED_VERSION_linux-yocto ?= "4.19%"
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
index 07dc5b77a1..36761b9943 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
@@ -31,7 +31,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
 
 LINUX_KERNEL_TYPE = "preempt-rt"
 
-COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuarm64|qemuppc|qemumips)"
+COMPATIBLE_MACHINE = 
"(qemux86|qemux86-64|qemuarm|qemuarma15|qemuarm64|qemuppc|qemumips)"
 
 KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
index c6d1594a82..52dbabd7a4 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
@@ -24,7 +24,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}"
 
-COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm"
+COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm|qemuarma15"
 
 # Functionality flags
 KERNEL_FEATURES = ""
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
index 8a4355ee83..3ef26a12ba 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
@@ -37,7 +37,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
 
 KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
 
-COMPATIBLE_MACHINE = 
"qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
+COMPATIBLE_MACHINE = 
"qemuarm|qemuarma15|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
 
 # Functionality flags
 KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
-- 
2.17.2

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

[OE-core] [OE-Core][PATCH v2 0/3] qemuarm: new machine and graphics

[Jon Mason]

v2 fixes the issues from the RFC.  Specifically, fix the qemuarm64 error
in testimage (and make a similar change in qemuarma15).

The kernel-config changes were already pulled in.  So this series should
"just work".

However, this series lacks the fix mentioned in
https://lists.yoctoproject.org/pipermail/linux-yocto/2019-February/007585.html
as I was unable to get it working.  This can be added as a follow-on
patch.

Thanks,
Jon

Jon Mason (3):
  qemuarm64: config cleanups
  qemuarm64: Add graphics support
  qemuarma15: ARM A15 Support

 meta/conf/machine/qemuarm64.conf  | 17 +++---
 meta/conf/machine/qemuarma15.conf | 33 +++
 .../linux/linux-yocto-rt_4.19.bb  |  2 +-
 .../linux/linux-yocto-tiny_4.19.bb|  2 +-
 meta/recipes-kernel/linux/linux-yocto_4.19.bb |  2 +-
 5 files changed, 48 insertions(+), 8 deletions(-)
 create mode 100644 meta/conf/machine/qemuarma15.conf

-- 
2.17.2

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

[OE-core] [OE-Core][PATCH v2 1/3] qemuarm64: config cleanups

[Jon Mason]

Add comments describing what is going on, remove an unnecessary space,
remove a duplicate comment, and increase the serial speed.

Signed-off-by: Jon Mason 
---
 meta/conf/machine/qemuarm64.conf | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index ee19385eaf..43078588a8 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -7,20 +7,23 @@ require conf/machine/include/qemu.inc
 
 KERNEL_IMAGETYPE = "Image"
 
-SERIAL_CONSOLES ?= "38400;ttyAMA0 38400;hvc0"
+SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
 
 # For runqemu
 QB_SYSTEM_NAME = "qemu-system-aarch64"
 QB_MEM = "-m 512"
 QB_MACHINE = "-machine virt"
 QB_CPU = "-cpu cortex-a57"
-QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0,38400"
-# Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
+# Standard Serial console and graphics (or lack thereof in this instance)
+QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0"
 QB_OPT_APPEND = "-show-cursor -monitor null"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
+# Virtio Networking support
 QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
 QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
+# Virtio block device
 QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device 
virtio-blk-device,drive=disk0"
+# Virtio serial console
 QB_SERIAL_OPT = "-device virtio-serial-device -chardev null,id=virtcon -device 
virtconsole,chardev=virtcon"
-QB_TCPSERIAL_OPT = " -device virtio-serial-device -chardev 
socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device 
virtconsole,chardev=virtcon"
+QB_TCPSERIAL_OPT = "-device virtio-serial-device -chardev 
socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device 
virtconsole,chardev=virtcon"
-- 
2.17.2

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

Re: [OE-core] [PATCH] rng-tools: Fix crazy defaults

[Richard Purdie]

On Tue, 2019-03-05 at 07:03 +, Rasmus Villemoes wrote:
> On 09/11/2018 09.54, Hongxu Jia wrote:
> >  Before=sysinit.target
> >  
> >  [Service]
> > -ExecStart=@SBINDIR@/rngd -f -r /dev/urandom
> > +ExecStart=@SBINDIR@/rngd -f -r /dev/hwrng
> >  SuccessExitStatus=66
> >  
> >  [Install]
> > 
> 
> This has been applied to master, but please apply this to thud as
> well -
> feeding the kernel's entropy pool from that same entropy pool is of
> course utter nonsense, but since rngd is also _crediting those bytes
> with providing real bits of entropy_ (ioctl RNDADDENTROPY) makes it a
> security issue.

Thanks for pointing this out, I've backported this to thud after
discussion with Armin.

Cheers,

Richard

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

Re: [OE-core] [meta-oe][thud][PATCH] target-sdk-provides-dummy: add perl-module-overload

[Oleksandr Kravchuk]

Apologies for skipping the commit message.

It fixes the following issue:

Error: 
 Problem: package perl-module-overload-5.24.4-r0.corei7_64 requires
perl-module-warnings-register, but none of the providers can be installed
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
conflicts with perl provided by perl-5.24.4-r0.corei7_64
 
On 04/03/2019 16:25, akuster808 wrote:
>
> On 3/3/19 8:18 PM, Oleksandr Kravchuk wrote:
>> Signed-off-by: Oleksandr Kravchuk 
> is this in master? What does it fix?
>
> - armin
>> ---
>>  meta/recipes-core/meta/target-sdk-provides-dummy.bb | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb 
>> b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
>> index edf07c4a23..13741f0a64 100644
>> --- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
>> +++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
>> @@ -26,6 +26,7 @@ DUMMYPROVIDES = "\
>>  perl-module-getopt-long \
>>  perl-module-io-file \
>>  perl-module-posix \
>> +perl-module-overload \
>>  perl-module-thread-queue \
>>  perl-module-threads \
>>  /bin/sh \
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] insane.bbclass: fix QA-check to consider the PREFERRED_RPROVIDER for RDEPENDS

[Catalin Dan Udma]

QA-check looks in the RDEPENDS list without taking into consideration that a
specific package may have a PREFERRED_RPROVIDER defined.
If PREFERRED_RPROVIDER is set, QA-check will ignore that settings and will
consider the original package, resulting in QA-check errors:
ERROR: do_packate_qa: QA Issue: <...>, but no providers found in
RDEPENDS_? [file-rdeps]
The fix is to replace the original package in the QA-check with the new
package defined in PREFERRED_RPROVIDER, if it’s set.

Signed-off-by: Catalin Udma 
---
 meta/classes/insane.bbclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 6411884..165233b 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -689,6 +689,9 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, taskdeps, 
packages, d):
 # Now do the sanity check!!!
 if "build-deps" not in skip:
 for rdepend in rdepends:
+pref_rdepend = localdata.getVar("PREFERRED_RPROVIDER_%s" % 
rdepend)
+if pref_rdepend:
+rdepend = pref_rdepend
 if "-dbg" in rdepend and "debug-deps" not in skip:
 error_msg = "%s rdepends on %s" % (pkg,rdepend)
 package_qa_handle_error("debug-deps", error_msg, d)
@@ -739,6 +742,9 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, taskdeps, 
packages, d):
 while next:
 new = []
 for rdep in next:
+pref_rdep = localdata.getVar("PREFERRED_RPROVIDER_%s" 
% rdep)
+if pref_rdep:
+rdep = pref_rdep
 rdep_data = oe.packagedata.read_subpkgdata(rdep, d)
 sub_rdeps = rdep_data.get("RDEPENDS_" + rdep)
 if not sub_rdeps:
-- 
2.7.4

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

Re: [OE-core] [thud][PATCH] openssl10: Fix mutliple include assumptions for des.h in opensslconf.h

[akuster808]

On 3/4/19 5:12 PM, Denys Dmytriyenko wrote:
> Armin,
>
> Not sure when would be the next batch of thud backports - as discussed 
> earlier, I needed this fix to un-break the last set of backported updates 
> from last Monday. Please let me know when this can be merged to thud.
> Thanks!
got it and is being built

- armin

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

[OE-core] [PATCH 5/5] libpng: fix CVE-2019-7317

[Ross Burton]

Signed-off-by: Ross Burton 
---
 .../libpng/libpng/CVE-2019-7317.patch| 20 
 meta/recipes-multimedia/libpng/libpng_1.6.36.bb  |  3 ++-
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-multimedia/libpng/libpng/CVE-2019-7317.patch

diff --git a/meta/recipes-multimedia/libpng/libpng/CVE-2019-7317.patch 
b/meta/recipes-multimedia/libpng/libpng/CVE-2019-7317.patch
new file mode 100644
index 000..6ee1f8da303
--- /dev/null
+++ b/meta/recipes-multimedia/libpng/libpng/CVE-2019-7317.patch
@@ -0,0 +1,20 @@
+Use-after-free detected with static analysis.
+
+CVE: CVE-2019-7317
+Upstream-Status: Submitted [https://github.com/glennrp/libpng/issues/275]
+Signed-off-by: Ross Burton 
+
+diff --git a/png.c b/png.c
+index 9d9926f638..efd1aecfbd 100644
+--- a/png.c
 b/png.c
+@@ -4588,8 +4588,7 @@ png_image_free(png_imagep image)
+if (image != NULL && image->opaque != NULL &&
+   image->opaque->error_buf == NULL)
+{
+-  /* Ignore errors here: */
+-  (void)png_safe_execute(image, png_image_free_function, image);
++  png_image_free_function(image);
+   image->opaque = NULL;
+}
+ }
diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.36.bb 
b/meta/recipes-multimedia/libpng/libpng_1.6.36.bb
index 3cf4f7249cb..a5862378884 100644
--- a/meta/recipes-multimedia/libpng/libpng_1.6.36.bb
+++ b/meta/recipes-multimedia/libpng/libpng_1.6.36.bb
@@ -9,7 +9,8 @@ DEPENDS = "zlib"
 
 LIBV = "16"
 
-SRC_URI = 
"${SOURCEFORGE_MIRROR}/project/${BPN}/${BPN}${LIBV}/${PV}/${BP}.tar.xz"
+SRC_URI = 
"${SOURCEFORGE_MIRROR}/project/${BPN}/${BPN}${LIBV}/${PV}/${BP}.tar.xz \
+   file://CVE-2019-7317.patch"
 SRC_URI[md5sum] = "df2be2d29c40937fe1f5349b16bc2826"
 SRC_URI[sha256sum] = 
"eceb924c1fa6b79172fdfd008d335f0e59172a86a66481e09d4089df872aa319"
 
-- 
2.11.0

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

[OE-core] [PATCH 1/5] libsndfile1: update security patches

[Ross Burton]

Remove CVE-2017-14245-14246.patch, fix rejected upstream as it doesn't solve the
underlying issue.

Instead 0001-a-ulaw-fix-multiple-buffer-overflows-432 also solves CVE-2017-14245
and CVE-2017-14246 properly.

Add patches for CVE-2017-12562 and CVE-2018-19758.

Refresh CVE-2018-13139.patch.

Signed-off-by: Ross Burton 
---
 ...-a-ulaw-fix-multiple-buffer-overflows-432.patch |  18 ++-
 .../libsndfile/libsndfile1/CVE-2017-12562.patch|  96 
 .../libsndfile1/CVE-2017-14245-14246.patch | 121 -
 .../libsndfile/libsndfile1/CVE-2018-13139.patch|  30 ++---
 .../libsndfile/libsndfile1/CVE-2018-19758.patch|  34 ++
 .../libsndfile/libsndfile1_1.0.28.bb   |   3 +-
 6 files changed, 160 insertions(+), 142 deletions(-)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-12562.patch
 delete mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14245-14246.patch
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2018-19758.patch

diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/0001-a-ulaw-fix-multiple-buffer-overflows-432.patch
 
b/meta/recipes-multimedia/libsndfile/libsndfile1/0001-a-ulaw-fix-multiple-buffer-overflows-432.patch
index c3f44ca235b..a4679cef2a0 100644
--- 
a/meta/recipes-multimedia/libsndfile/libsndfile1/0001-a-ulaw-fix-multiple-buffer-overflows-432.patch
+++ 
b/meta/recipes-multimedia/libsndfile/libsndfile1/0001-a-ulaw-fix-multiple-buffer-overflows-432.patch
@@ -1,3 +1,15 @@
+This patch fixes #429 (CVE-2018-19661 CVE-2018-19662) and #344 (CVE-2017-17456
+CVE-2017-17457). As per
+https://github.com/erikd/libsndfile/issues/344#issuecomment-448504425 it also
+fixes #317 (CVE-2017-14245 CVE-2017-14246).
+
+CVE: CVE-2017-14245 CVE-2017-14246
+CVE: CVE-2017-17456 CVE-2017-17457
+CVE: CVE-2018-19661 CVE-2018-19662
+
+Upstream-Status: Backport [8ddc442d539ca775d80cdbc7af17a718634a743f]
+Signed-off-by: Ross Burton 
+
 From 39453899fe1bb39b2e041fdf51a85aecd177e9c7 Mon Sep 17 00:00:00 2001
 From: Changqing Li 
 Date: Mon, 7 Jan 2019 15:55:03 +0800
@@ -17,12 +29,6 @@ In this case, arbitrarily set the buffer value to 0.
 This commit fixes #429 (CVE-2018-19661 and CVE-2018-19662) and
 fixes #344 (CVE-2017-17456 and CVE-2017-17457).
 
-Upstream-Status: Backport[https://github.com/erikd/libsndfile/
-commit/585cc28a93be27d6938f276af0011401b9f7c0ca]
-
-CVE: CVE-2017-17456 CVE-2017-17457 CVE-2018-19661 CVE-2018-19662
-
-Signed-off-by: Changqing Li 
 ---
  src/alaw.c | 9 +++--
  src/ulaw.c | 9 +++--
diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-12562.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-12562.patch
new file mode 100644
index 000..491dae31148
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-12562.patch
@@ -0,0 +1,96 @@
+Heap-based Buffer Overflow in the psf_binheader_writef function in common.c in
+libsndfile through 1.0.28 allows remote attackers to cause a denial of service
+(application crash) or possibly have unspecified other impact.
+
+CVE: CVE-2017-12562
+Upstream-Status: Backport [cf7a8182c2642c50f1cf90dddea9ce96a8bad2e8]
+Signed-off-by: Ross Burton 
+
+From b6a9d7e95888ffa77d8c75ce3f03e6c7165587cd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=B6rn=20Heusipp?= 
+Date: Wed, 14 Jun 2017 12:25:40 +0200
+Subject: [PATCH] src/common.c: Fix heap buffer overflows when writing strings
+ in binheader
+
+Fixes the following problems:
+ 1. Case 's' only enlarges the buffer by 16 bytes instead of size bytes.
+ 2. psf_binheader_writef() enlarges the header buffer (if needed) prior to the
+big switch statement by an amount (16 bytes) which is enough for all cases
+where only a single value gets added. Cases 's', 'S', 'p' however
+additionally write an arbitrary length block of data and again enlarge the
+buffer to the required amount. However, the required space calculation does
+not take into account the size of the length field which gets output before
+the data.
+ 3. Buffer size requirement calculation in case 'S' does not account for the
+padding byte ("size += (size & 1) ;" happens after the calculation which
+uses "size").
+ 4. Case 'S' can overrun the header buffer by 1 byte when no padding is
+involved
+("memcpy (&(psf->header.ptr [psf->header.indx]), strptr, size + 1) ;" while
+the buffer is only guaranteed to have "size" space available).
+ 5. "psf->header.ptr [psf->header.indx] = 0 ;" in case 'S' always writes 1 byte
+beyond the space which is guaranteed to be allocated in the header buffer.
+ 6. Case 's' can overrun the provided source string by 1 byte if padding is
+involved ("memcpy (&(psf->header.ptr [psf->header.indx]), strptr, size) ;"
+where "size" is "strlen (strptr) + 1" (which includes the 0 terminator,
+plus optionally another 1 which is padding and not guaranteed to be
+readable via the source string 

[OE-core] [PATCH 4/5] libarchive: integrate security fixes

[Ross Burton]

Fix the following CVEs by backporting patches from upstream:
- CVE-2019-119
- CVE-2019-120
- CVE-2018-1000877
- CVE-2018-1000878
- CVE-2018-1000879
- CVE-2018-1000880

Signed-off-by: Ross Burton 
---
 .../libarchive/libarchive/CVE-2018-1000877.patch   | 38 +++
 .../libarchive/libarchive/CVE-2018-1000878.patch   | 79 ++
 .../libarchive/libarchive/CVE-2018-1000879.patch   | 50 ++
 .../libarchive/libarchive/CVE-2018-1000880.patch   | 44 
 .../libarchive/libarchive/CVE-2019-119.patch   | 59 
 .../libarchive/libarchive/CVE-2019-120.patch   | 61 +
 .../libarchive/libarchive_3.3.3.bb |  6 ++
 7 files changed, 337 insertions(+)
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2018-1000877.patch
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2018-1000878.patch
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2018-1000879.patch
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2018-1000880.patch
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2019-119.patch
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2019-120.patch

diff --git a/meta/recipes-extended/libarchive/libarchive/CVE-2018-1000877.patch 
b/meta/recipes-extended/libarchive/libarchive/CVE-2018-1000877.patch
new file mode 100644
index 000..ce638370bd4
--- /dev/null
+++ b/meta/recipes-extended/libarchive/libarchive/CVE-2018-1000877.patch
@@ -0,0 +1,38 @@
+CVE: CVE-2018-1000877
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From 021efa522ad729ff0f5806c4ce53e4a6cc1daa31 Mon Sep 17 00:00:00 2001
+From: Daniel Axtens 
+Date: Tue, 20 Nov 2018 17:56:29 +1100
+Subject: [PATCH] Avoid a double-free when a window size of 0 is specified
+
+new_size can be 0 with a malicious or corrupted RAR archive.
+
+realloc(area, 0) is equivalent to free(area), so the region would
+be free()d here and the free()d again in the cleanup function.
+
+Found with a setup running AFL, afl-rb, and qsym.
+---
+ libarchive/archive_read_support_format_rar.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/libarchive/archive_read_support_format_rar.c 
b/libarchive/archive_read_support_format_rar.c
+index 2345..6f419c27 100644
+--- a/libarchive/archive_read_support_format_rar.c
 b/libarchive/archive_read_support_format_rar.c
+@@ -2300,6 +2300,11 @@ parse_codes(struct archive_read *a)
+   new_size = DICTIONARY_MAX_SIZE;
+ else
+   new_size = rar_fls((unsigned int)rar->unp_size) << 1;
++if (new_size == 0) {
++  archive_set_error(>archive, ARCHIVE_ERRNO_FILE_FORMAT,
++"Zero window size is invalid.");
++  return (ARCHIVE_FATAL);
++}
+ new_window = realloc(rar->lzss.window, new_size);
+ if (new_window == NULL) {
+   archive_set_error(>archive, ENOMEM,
+-- 
+2.20.0
+
diff --git a/meta/recipes-extended/libarchive/libarchive/CVE-2018-1000878.patch 
b/meta/recipes-extended/libarchive/libarchive/CVE-2018-1000878.patch
new file mode 100644
index 000..7468fd3c935
--- /dev/null
+++ b/meta/recipes-extended/libarchive/libarchive/CVE-2018-1000878.patch
@@ -0,0 +1,79 @@
+CVE: CVE-2018-1000878
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From bfcfe6f04ed20db2504db8a254d1f40a1d84eb28 Mon Sep 17 00:00:00 2001
+From: Daniel Axtens 
+Date: Tue, 4 Dec 2018 00:55:22 +1100
+Subject: [PATCH] rar: file split across multi-part archives must match
+
+Fuzzing uncovered some UAF and memory overrun bugs where a file in a
+single file archive reported that it was split across multiple
+volumes. This was caused by ppmd7 operations calling
+rar_br_fillup. This would invoke rar_read_ahead, which would in some
+situations invoke archive_read_format_rar_read_header.  That would
+check the new file name against the old file name, and if they didn't
+match up it would free the ppmd7 buffer and allocate a new
+one. However, because the ppmd7 decoder wasn't actually done with the
+buffer, it would continue to used the freed buffer. Both reads and
+writes to the freed region can be observed.
+
+This is quite tricky to solve: once the buffer has been freed it is
+too late, as the ppmd7 decoder functions almost universally assume
+success - there's no way for ppmd_read to signal error, nor are there
+good ways for functions like Range_Normalise to propagate them. So we
+can't detect after the fact that we're in an invalid state - e.g. by
+checking rar->cursor, we have to prevent ourselves from ever ending up
+there. So, when we are in the dangerous part or rar_read_ahead that
+assumes a valid split, we set a flag force read_header to either go
+down the path for split files or bail. This means that the ppmd7
+decoder keeps a valid buffer and just runs out of data.
+
+Found with a combination of AFL, afl-rb and qsym.
+---
+ libarchive/archive_read_support_format_rar.c | 9 

[OE-core] [PATCH 2/5] icu: fix CVE-2018-18928

[Ross Burton]

Signed-off-by: Ross Burton 
---
 meta/recipes-support/icu/icu/CVE-2018-18928.patch | 63 +++
 meta/recipes-support/icu/icu_63.1.bb  |  1 +
 2 files changed, 64 insertions(+)
 create mode 100644 meta/recipes-support/icu/icu/CVE-2018-18928.patch

diff --git a/meta/recipes-support/icu/icu/CVE-2018-18928.patch 
b/meta/recipes-support/icu/icu/CVE-2018-18928.patch
new file mode 100644
index 000..19c50e4e76a
--- /dev/null
+++ b/meta/recipes-support/icu/icu/CVE-2018-18928.patch
@@ -0,0 +1,63 @@
+CVE: CVE-2018-18928
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From 53d8c8f3d181d87a6aa925b449b51c4a2c922a51 Mon Sep 17 00:00:00 2001
+From: Shane Carr 
+Date: Mon, 29 Oct 2018 23:52:44 -0700
+Subject: [PATCH] ICU-20246 Fixing another integer overflow in number parsing.
+
+---
+ i18n/fmtable.cpp  |  2 +-
+ i18n/number_decimalquantity.cpp   |  5 -
+ test/intltest/numfmtst.cpp|  8 
+ 6 files changed, 31 insertions(+), 4 deletions(-)
+
+diff --git a/i18n/fmtable.cpp b/i18n/fmtable.cpp
+index 45c7024fc29..8601d95f4a6 100644
+--- a/i18n/fmtable.cpp
 b/i18n/fmtable.cpp
+@@ -734,7 +734,7 @@ CharString *Formattable::internalGetCharString(UErrorCode 
) {
+   // not print scientific notation for magnitudes greater than -5 and 
smaller than some amount (+5?).
+   if (fDecimalQuantity->isZero()) {
+ fDecimalStr->append("0", -1, status);
+-  } else if (std::abs(fDecimalQuantity->getMagnitude()) < 5) {
++  } else if (fDecimalQuantity->getMagnitude() != INT32_MIN && 
std::abs(fDecimalQuantity->getMagnitude()) < 5) {
+ fDecimalStr->appendInvariantChars(fDecimalQuantity->toPlainString(), 
status);
+   } else {
+ 
fDecimalStr->appendInvariantChars(fDecimalQuantity->toScientificString(), 
status);
+diff --git a/i18n/number_decimalquantity.cpp b/i18n/number_decimalquantity.cpp
+index 47b930a564b..d5dd7ae694c 100644
+--- a/i18n/number_decimalquantity.cpp
 b/i18n/number_decimalquantity.cpp
+@@ -898,7 +898,10 @@ UnicodeString DecimalQuantity::toScientificString() const 
{
+ }
+ result.append(u'E');
+ int32_t _scale = upperPos + scale;
+-if (_scale < 0) {
++if (_scale == INT32_MIN) {
++result.append({u"-2147483648", -1});
++return result;
++} else if (_scale < 0) {
+ _scale *= -1;
+ result.append(u'-');
+ } else {
+diff --git a/test/intltest/numfmtst.cpp b/test/intltest/numfmtst.cpp
+index 34355939113..8d52dc122bf 100644
+--- a/test/intltest/numfmtst.cpp
 b/test/intltest/numfmtst.cpp
+@@ -9226,6 +9226,14 @@ void 
NumberFormatTest::Test20037_ScientificIntegerOverflow() {
+ assertEquals(u"Should not overflow and should parse only the first 
exponent",
+  u"1E-2147483647",
+  {sp.data(), sp.length(), US_INV});
++
++// Test edge case overflow of exponent
++result = Formattable();
++nf->parse(u".0003e-2147483644", result, status);
++sp = result.getDecimalNumber(status);
++assertEquals(u"Should not overflow",
++ u"3E-2147483648",
++ {sp.data(), sp.length(), US_INV});
+ }
+ 
+ void NumberFormatTest::Test13840_ParseLongStringCrash() {
diff --git a/meta/recipes-support/icu/icu_63.1.bb 
b/meta/recipes-support/icu/icu_63.1.bb
index e593dc1bdbd..961f022ad7a 100644
--- a/meta/recipes-support/icu/icu_63.1.bb
+++ b/meta/recipes-support/icu/icu_63.1.bb
@@ -17,6 +17,7 @@ SRC_URI = "${BASE_SRC_URI} \
file://icu-pkgdata-large-cmd.patch \
file://fix-install-manx.patch \
file://0002-Add-ARC-support.patch \
+   file://CVE-2018-18928.patch \
"
 
 SRC_URI_append_class-target = "\
-- 
2.11.0

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

[OE-core] [PATCH 3/5] file: upgrade to 5.36

[Ross Burton]

Upgrade to 5.36.

Drop debian-742262.patch, this appears to have been fixed properly upstream some
releases ago.

Signed-off-by: Ross Burton 
---
 .../recipes-devtools/file/file/debian-742262.patch | 27 --
 .../file/{file_5.35.bb => file_5.36.bb}|  6 ++---
 2 files changed, 2 insertions(+), 31 deletions(-)
 delete mode 100644 meta/recipes-devtools/file/file/debian-742262.patch
 rename meta/recipes-devtools/file/{file_5.35.bb => file_5.36.bb} (90%)

diff --git a/meta/recipes-devtools/file/file/debian-742262.patch 
b/meta/recipes-devtools/file/file/debian-742262.patch
deleted file mode 100644
index 319f9dbcf9b..000
--- a/meta/recipes-devtools/file/file/debian-742262.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-The awk pattern was checked *before* the Perl pattern, so the
-perl script with BEGIN{...} would be reported as awk, this patch fixes it.
-
-Upstream-Status: Backport [debian]
-
-Signed-off-by: Christoph Biedl 
-Signed-off-by: Robert Yang 
-
-Rebase on 5.31
-
-Signed-off-by: Fan Xin 

- magic/Magdir/commands | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/magic/Magdir/commands b/magic/Magdir/commands
-index f6ad1c8..f79e7dd 100644
 a/magic/Magdir/commands
-+++ b/magic/Magdir/commands
-@@ -57,6 +57,7 @@
- 0 string/wt   #!\ /usr/bin/awkawk script text executable
- !:mimetext/x-awk
- 0 regex/4096  =^[\040\t\f\r\n]{0,100}BEGIN[\040\t\f\r\n]{0,100}[{]
awk or perl script text
-+!:strength - 12
- 
- # AT Bell Labs' Plan 9 shell
- 0 string/wt   #!\ /bin/rc Plan 9 rc shell script text executable
diff --git a/meta/recipes-devtools/file/file_5.35.bb 
b/meta/recipes-devtools/file/file_5.36.bb
similarity index 90%
rename from meta/recipes-devtools/file/file_5.35.bb
rename to meta/recipes-devtools/file/file_5.36.bb
index 2f0589de686..1a81fde259d 100644
--- a/meta/recipes-devtools/file/file_5.35.bb
+++ b/meta/recipes-devtools/file/file_5.36.bb
@@ -14,11 +14,9 @@ DEPENDS_class-native = "zlib-native"
 # Blacklist a bogus tag in upstream check
 UPSTREAM_CHECK_GITTAGREGEX = "FILE(?P(?!6_23).+)"
 
-SRC_URI = "git://github.com/file/file.git \
-file://debian-742262.patch \
-"
+SRC_URI = "git://github.com/file/file.git"
 
-SRCREV = "d1ff3af7a2c6b38bdbdde7af26b59e3c50a48fff"
+SRCREV = "f3a4b9ada3ca99e62c62b9aa78eee4935a8094fe"
 S = "${WORKDIR}/git"
 
 inherit autotools update-alternatives
-- 
2.11.0

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

[OE-core] Yocto Project Status WW10'19

[sjolley.yp.pm]

Current Dev Position: YP 2.7 M3 (New feature Freeze has begun.)

Next Deadline: YP 2.7 M3 Cutoff was Feb. 25, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Ross
*   SWAT team rotation: Chen -> Anuj on Mar. 8, 2019
*   SWAT team rotation: Anuj -> Armin on Mar. 15, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Key Status/Updates:

*   YP 2.7 M2 rc2 is being released today Mar. 5, 2019.
*   YP 2.7 M3 has not yet been built but progress has been made in
resolving several issues:

*   bug 13178 "X server and matchbox desktop don't start up properly on
beaglebone" was fixed
*   multiconfig bugs have been fixed and a test case added
*   qemu virgl code and selftests have been added (not enabled as
default)
*   qemu native build was split into user and system components
*   lttng-tools ptest timeout fixed
*   systemd version upgrade
*   ltp recipe version upgrade
*   perl ptest regressions fixed

*   The list of remaining potential items for M3 is:

*   5.0 linux kernel (and libc headers) (Bruce)
*   qemuarm to v7 changes (Jon)
*   Aarch64 build host support finalization (Jon)
*   Busybox 'full' utility replacement (Tom)

*   YP 2.5.3 is nearly ready for building however the autobuilder-helper
changes need to be resolved for the stable branches, as do the resulttool
changes in master to move to the new QA process.

 

Planned Releases for YP 2.7:

*   YP 2.7 M2 Released Mar. 5, 2019
*   YP 2.7 M3 Cutoff is Feb. 25, 2019
*   YP 2.7 M3 Release Target is Mar. 8, 2019
*   YP 2.7 M4 Cutoff is Apr. 1, 2019
*   YP 2.7 M4 Release Target is Apr. 26, 2019

 

Planned upcoming dot releases:

*   YP 2.5.3 (Sumo) will be targeted after YP 2.7 M2 is done.
*   YP 2.5.4 (Sumo) will be targeted after YP 2.7 M4 is done.
*   YP 2.6.2 (Thud) will be targeted after YP 2.5.4 is done.

 

Tracking Metrics:

*   WDD 2436 (last week 2415) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1502 (last week 1516)
*   Patches in the Pending State: 658 (44%) [last week 660 (44%)]

 

Key Status Links for YP:

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

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

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

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

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

Re: [OE-core] [PATCH] Add source package to ${PACKAGES}

[Joshua Watt]

On Tue, 2019-03-05 at 11:19 +, Burton, Ross wrote:
> On Tue, 5 Mar 2019 at 02:46, Joshua Watt 
> wrote:
> > +ALLOW_EMPTY_${PN}-src = "1"
> 
> Is that what we want?  Empty PN-src packages for packages which have
> no source code, or when source splitting is disabled?

I found this while attempting to "targeted" debugging where I only put
the -dbg packages for the things I actually wanted to debug on the root
file system (as opposed to using the "dbg-pkgs src-pkgs"
IMAGE_FEATURES), i.e. IMAGE_INSTALL += "foo-dbg"

The problem I encountered was that I couldn't do the same thing with
the source packages (i.e. IMAGE_INSTALL += "foo-src") because they
don't exist at parsing time.


> 
> Ross
-- 
Joshua Watt 

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

[OE-core] [PATCH] libsndfile1: update security patches

[Ross Burton]

Remove CVE-2017-14245-14246.patch as this papers over the problem instead of
solving it, and was rejected upstream.

0001-a-ulaw-fix-multiple-buffer-overflows-432 also solves CVE-2017-14245 and
-14246 properly.

Add patch for CVE-2017-12562 and CVE-2018-19758.

Refresh CVE-2018-13139.patch.

Signed-off-by: Ross Burton 
---
 ...-a-ulaw-fix-multiple-buffer-overflows-432.patch |  18 ++-
 .../libsndfile/libsndfile1/CVE-2017-12562.patch|  96 
 .../libsndfile1/CVE-2017-14245-14246.patch | 121 -
 .../libsndfile/libsndfile1/CVE-2018-13139.patch|  30 ++---
 .../libsndfile/libsndfile1/CVE-2018-19758.patch|  34 ++
 .../libsndfile/libsndfile1_1.0.28.bb   |   3 +-
 6 files changed, 160 insertions(+), 142 deletions(-)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-12562.patch
 delete mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-14245-14246.patch
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2018-19758.patch

diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/0001-a-ulaw-fix-multiple-buffer-overflows-432.patch
 
b/meta/recipes-multimedia/libsndfile/libsndfile1/0001-a-ulaw-fix-multiple-buffer-overflows-432.patch
index c3f44ca235b..a4679cef2a0 100644
--- 
a/meta/recipes-multimedia/libsndfile/libsndfile1/0001-a-ulaw-fix-multiple-buffer-overflows-432.patch
+++ 
b/meta/recipes-multimedia/libsndfile/libsndfile1/0001-a-ulaw-fix-multiple-buffer-overflows-432.patch
@@ -1,3 +1,15 @@
+This patch fixes #429 (CVE-2018-19661 CVE-2018-19662) and #344 (CVE-2017-17456
+CVE-2017-17457). As per
+https://github.com/erikd/libsndfile/issues/344#issuecomment-448504425 it also
+fixes #317 (CVE-2017-14245 CVE-2017-14246).
+
+CVE: CVE-2017-14245 CVE-2017-14246
+CVE: CVE-2017-17456 CVE-2017-17457
+CVE: CVE-2018-19661 CVE-2018-19662
+
+Upstream-Status: Backport [8ddc442d539ca775d80cdbc7af17a718634a743f]
+Signed-off-by: Ross Burton 
+
 From 39453899fe1bb39b2e041fdf51a85aecd177e9c7 Mon Sep 17 00:00:00 2001
 From: Changqing Li 
 Date: Mon, 7 Jan 2019 15:55:03 +0800
@@ -17,12 +29,6 @@ In this case, arbitrarily set the buffer value to 0.
 This commit fixes #429 (CVE-2018-19661 and CVE-2018-19662) and
 fixes #344 (CVE-2017-17456 and CVE-2017-17457).
 
-Upstream-Status: Backport[https://github.com/erikd/libsndfile/
-commit/585cc28a93be27d6938f276af0011401b9f7c0ca]
-
-CVE: CVE-2017-17456 CVE-2017-17457 CVE-2018-19661 CVE-2018-19662
-
-Signed-off-by: Changqing Li 
 ---
  src/alaw.c | 9 +++--
  src/ulaw.c | 9 +++--
diff --git 
a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-12562.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-12562.patch
new file mode 100644
index 000..491dae31148
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2017-12562.patch
@@ -0,0 +1,96 @@
+Heap-based Buffer Overflow in the psf_binheader_writef function in common.c in
+libsndfile through 1.0.28 allows remote attackers to cause a denial of service
+(application crash) or possibly have unspecified other impact.
+
+CVE: CVE-2017-12562
+Upstream-Status: Backport [cf7a8182c2642c50f1cf90dddea9ce96a8bad2e8]
+Signed-off-by: Ross Burton 
+
+From b6a9d7e95888ffa77d8c75ce3f03e6c7165587cd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=B6rn=20Heusipp?= 
+Date: Wed, 14 Jun 2017 12:25:40 +0200
+Subject: [PATCH] src/common.c: Fix heap buffer overflows when writing strings
+ in binheader
+
+Fixes the following problems:
+ 1. Case 's' only enlarges the buffer by 16 bytes instead of size bytes.
+ 2. psf_binheader_writef() enlarges the header buffer (if needed) prior to the
+big switch statement by an amount (16 bytes) which is enough for all cases
+where only a single value gets added. Cases 's', 'S', 'p' however
+additionally write an arbitrary length block of data and again enlarge the
+buffer to the required amount. However, the required space calculation does
+not take into account the size of the length field which gets output before
+the data.
+ 3. Buffer size requirement calculation in case 'S' does not account for the
+padding byte ("size += (size & 1) ;" happens after the calculation which
+uses "size").
+ 4. Case 'S' can overrun the header buffer by 1 byte when no padding is
+involved
+("memcpy (&(psf->header.ptr [psf->header.indx]), strptr, size + 1) ;" while
+the buffer is only guaranteed to have "size" space available).
+ 5. "psf->header.ptr [psf->header.indx] = 0 ;" in case 'S' always writes 1 byte
+beyond the space which is guaranteed to be allocated in the header buffer.
+ 6. Case 's' can overrun the provided source string by 1 byte if padding is
+involved ("memcpy (&(psf->header.ptr [psf->header.indx]), strptr, size) ;"
+where "size" is "strlen (strptr) + 1" (which includes the 0 terminator,
+plus optionally another 1 which is padding and not guaranteed to be
+readable via the source string pointer).

Re: [OE-core] [OE-Core][master][PATCH] standard.py: Provide an additional option for devtool reset

[Manjukumar Harthikote Matha]

Hi Paul,

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Paul
> Eggleton
> Sent: Monday, March 04, 2019 12:17 PM
> To: openembedded-core@lists.openembedded.org; Chandana Kalluri
> 
> Subject: Re: [OE-core] [OE-Core][master][PATCH] standard.py: Provide an 
> additional
> option for devtool reset
> 
> On Friday, 8 February 2019 2:57:32 PM NZDT Sai Hari Chandana Kalluri wrote:
> > The devtool reset command cleans the sysroot for a recipe in workspace.
> > It also removes the append file but leaves the source code as in
> > workspace. The source is not cleaned intentionally and the user has to
> > manually remove it before calling devtool modify again.
> >
> > Provide the user with an option to remove the source code from
> > workspace by adding a flag to the devtool reset command. The
> > --rm-source option for the devtool reset command will also clean the
> > source code from the workspace along with the sysroot and the append file.
> > Ex: devtool reset --rm-source zip or devtool reset -r zip
> 
> When I wrote this I made a conscious decision not to delete the source, in 
> case the
> user has unsaved work in the source tree; at least then the user has to take 
> an
> explicit step (an additional rm -rf) in order to delete it. You might argue 
> that adding
> an option is the same as that explicit step, but I am still hesitant as you 
> might for
> example pick a previously used command from your command history with -r in it
> and only realise after you've run it that you've just blown away a bunch of 
> your
> work.
> 
> However, I have received the feedback from a number of people that they find 
> it
> annoying that they have to delete the source themselves before being able to 
> run
> devtool on the recipe again. I'd like to hear from the wider community on the
> following two questions:
> 
> 1) Does the convenience of having this kind of option outweigh the potential 
> danger
> of deleting unsaved work?
> 
> 2) Are there issues that anyone is experiencing that force you to run devtool
> clean/finish and then re-run devtool modify (or add, or upgrade), making this 
> kind of
> situation come up more frequently? Or is it mostly that the source 
> directories end up
> being left around to stumble over some time later?

We have seen source directories end up being left around (taking more disk 
space on certain projects), hence a solution to remove it might be optimal. If 
the preference is not have "-r" option to avoid command history mistake, then a 
full command like devtool reset --rm-source is acceptable as well

Thanks,
Manju

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

Re: [OE-core] [PATCH 0/3] Upgrade systemd to 241

[Alex Kiernan]

On Fri, Mar 1, 2019 at 8:42 AM Chen Qi  wrote:
>
>
> The following changes since commit 4d275d97b6c572fe11668ac16d2c77c018340c7c:
>
>   perl: apply a native-only patch only to -native (2019-02-28 17:49:40 +)
>
> are available in the git repository at:
>
>   git://git.pokylinux.org/poky-contrib ChenQi/systemd-241
>   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/systemd-241
>
> Chen Qi (3):
>   systemd: upgrade to 241
>   systemd-conf: add version info in recipe name
>   systemd-boot: upgrade to 241
>

This upgrade seems to cause problems with the on-disk timestamp for
systemd-timesyncd. Having started writing what goes on, it's actually
in the systemd NEWS for 240:

* DynamicUser=yes is dropped from systemd-networkd.service,
  systemd-resolved.service and systemd-timesyncd.service, which was
  enabled in v239 for systemd-networkd.service and systemd-resolved.service,
  and since v236 for systemd-timesyncd.service. The users and groups
  systemd-network, systemd-resolve and systemd-timesync are created
  by systemd-sysusers again. Distributors or system administrators
  may need to create these users and groups if they not exist (or need
  to re-enable DynamicUser= for those units) while upgrading systemd.
  Also, the clock file for systemd-timesyncd may need to move from
  /var/lib/private/systemd/timesync/clock to /var/lib/systemd/timesync/clock.

It's the last bit that's tripping things up. I'm not sure I can think
of a good way of expressing that fixup using tmpfiles. I can use a
ConditionNeedsUpdate=/var to catch it locally (I'm using OSTree, and
OSTree successfully triggers that), but I don't know how useful that
approach will be to others.

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

Re: [OE-core] [PATCH] rng-tools: Fix crazy defaults

[Rasmus Villemoes]

On 09/11/2018 09.54, Hongxu Jia wrote:
> Since commit [f1dc9ac rng-tools: Fix crazy defaults] fixed
> init based on sysvinit, this fix rngd.service based on systemd.
> 
> Signed-off-by: Hongxu Jia 
> ---
>  meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service 
> b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> index cb81024..f0355db 100644
> --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> @@ -5,7 +5,7 @@ After=systemd-udev-settle.service
>  Before=sysinit.target
>  
>  [Service]
> -ExecStart=@SBINDIR@/rngd -f -r /dev/urandom
> +ExecStart=@SBINDIR@/rngd -f -r /dev/hwrng
>  SuccessExitStatus=66
>  
>  [Install]
> 

This has been applied to master, but please apply this to thud as well -
feeding the kernel's entropy pool from that same entropy pool is of
course utter nonsense, but since rngd is also _crediting those bytes
with providing real bits of entropy_ (ioctl RNDADDENTROPY) makes it a
security issue.

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

Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

[Ricardo Ribalda Delgado]

Yes, but I want to do it slightly differently

Instead of a big package with all the blobs I want to split it in
something that mimics the current package structure.
Also I want to run it inside a multiconfig setup.

Once everything works I want to upstream it to mesa-tegra.

On Tue, Mar 5, 2019 at 12:17 PM Burton, Ross  wrote:
>
> Isn't this something that https://github.com/madisongh/meta-tegra already 
> does?
>
> Ross
>
> On Tue, 5 Mar 2019 at 11:10, Ricardo Ribalda Delgado
>  wrote:
> >
> > This is my approach (which is not more than a horrible hack)
> >
> > DESCRIPTION = "Tegra replacements for mesa libraries"
> > require recipes-bsp/tegra-binaries/tegra-glvnd.inc
> > RDEPENDS_libgl-mesa = "tegra-lib-common libegl-mesa libxcb-glx
> > libxxf86vm libxdamage libxcb-xfixes"
> > RDEPENDS_libegl-mesa = "zlib libxcb-xfixes libxcb-present libdrm
> > libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> > libx11 libx11-xcb"
> > RDEPENDS_libgles2-mesa = "libdrm libglapi"
> > RDEPENDS_libgles1-mesa = "libdrm libglapi"
> > RPROVIDES_libgl-mesa += "gl-proprietary libgl"
> > RPROVIDES_libegl-mesa += "libegl"
> > RPROVIDES_libgles2-mesa += "libgles2"
> > RPROVIDES_libgles1-mesa += "libgles1"
> > PV = "${L4T_RELEASE}"
> > PE = "5"
> > PACKAGES = "libgl-mesa libegl-mesa libgles2-mesa libgles1-mesa"
> > L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> > L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> > L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
> > do_unpack_append() {
> > bb.build.exec_func("unpack_l4t_tar", d)
> > }
> > unpack_l4t_tar() {
> > install -d ${L4T_GLVND_DIR}
> > tar -C ${L4T_GLVND_DIR} -x -f \
> > ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> > usr/lib/aarch64-linux-gnu/tegra \
> > usr/lib/aarch64-linux-gnu/tegra-egl
> > }
> > do_compile[noexec] = "1"
> > PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> > rm_pkgdata_runtime() {
> > rm -rf ${WORKDIR}/pkgdata/runtime/*
> > rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> > }
> > do_install() {
> > install -d ${D}${libdir}
> > # Install NVIDIA mesa libraries (libglvnd)
> > install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 
> > ${D}${libdir}/libGL.so.1.2.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 
> > ${D}${libdir}/libEGL.so.1.0.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> > ${D}${libdir}/libGLESv1_CM.so.1.1.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> > ${D}${libdir}/libGLESv2.so.2.0.0
> > ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> > ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> > ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
> > # Install extra NVIDIA libglvnd libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> > ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> > ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
> > # Install extra EGL NVIDIA libraries
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 
> > ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
> > # Install extra GL NVIDIA libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
> > # Install libraries dependent on libglvnd libs
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 
> > ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
> > # nvcamera_daemon and argus_daemon have hard-coded path for this
> > install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> > ln -sf ${libdir}/libEGL.so.1.0.0
> > ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
> > }
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> > FILES_libgles1-mesa += "\
> > ${libdir}/libGLESv1* \
> > "
> > FILES_libgles2-mesa += "\
> > ${libdir}/libGLESv2* \
> > "
> > FILES_libegl-mesa += "\
> > ${libdir}/libEGL* \
> > ${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
> > "
> > FILES_libgl-mesa += "\
> > ${libdir}/libGL.* \
> > ${libdir}/libGLX* \
> > ${libdir}/libGLdispatch.so* \
> > ${libdir}/libnvidia-glsi.so.28.2.1 \
> > ${libdir}/libnvbuf_utils.so* \
> > ${libdir}/libnvddk_vic.so  \
> > ${libdir}/libnvddk_2d_v2.so \
> 

Re: [OE-core] [PATCH] Add source package to ${PACKAGES}

[Burton, Ross]

On Tue, 5 Mar 2019 at 02:46, Joshua Watt  wrote:
> +ALLOW_EMPTY_${PN}-src = "1"

Is that what we want?  Empty PN-src packages for packages which have
no source code, or when source splitting is disabled?

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

Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

[Burton, Ross]

Isn't this something that https://github.com/madisongh/meta-tegra already does?

Ross

On Tue, 5 Mar 2019 at 11:10, Ricardo Ribalda Delgado
 wrote:
>
> This is my approach (which is not more than a horrible hack)
>
> DESCRIPTION = "Tegra replacements for mesa libraries"
> require recipes-bsp/tegra-binaries/tegra-glvnd.inc
> RDEPENDS_libgl-mesa = "tegra-lib-common libegl-mesa libxcb-glx
> libxxf86vm libxdamage libxcb-xfixes"
> RDEPENDS_libegl-mesa = "zlib libxcb-xfixes libxcb-present libdrm
> libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> libx11 libx11-xcb"
> RDEPENDS_libgles2-mesa = "libdrm libglapi"
> RDEPENDS_libgles1-mesa = "libdrm libglapi"
> RPROVIDES_libgl-mesa += "gl-proprietary libgl"
> RPROVIDES_libegl-mesa += "libegl"
> RPROVIDES_libgles2-mesa += "libgles2"
> RPROVIDES_libgles1-mesa += "libgles1"
> PV = "${L4T_RELEASE}"
> PE = "5"
> PACKAGES = "libgl-mesa libegl-mesa libgles2-mesa libgles1-mesa"
> L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
> do_unpack_append() {
> bb.build.exec_func("unpack_l4t_tar", d)
> }
> unpack_l4t_tar() {
> install -d ${L4T_GLVND_DIR}
> tar -C ${L4T_GLVND_DIR} -x -f \
> ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> usr/lib/aarch64-linux-gnu/tegra \
> usr/lib/aarch64-linux-gnu/tegra-egl
> }
> do_compile[noexec] = "1"
> PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> rm_pkgdata_runtime() {
> rm -rf ${WORKDIR}/pkgdata/runtime/*
> rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> }
> do_install() {
> install -d ${D}${libdir}
> # Install NVIDIA mesa libraries (libglvnd)
> install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
> install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 
> ${D}${libdir}/libEGL.so.1.0.0
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> ${D}${libdir}/libGLESv1_CM.so.1.1.0
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> ${D}${libdir}/libGLESv2.so.2.0.0
> ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
> # Install extra NVIDIA libglvnd libraries
> install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
> # Install extra EGL NVIDIA libraries
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
> # Install extra GL NVIDIA libraries
> install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
> # Install libraries dependent on libglvnd libs
> install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
> install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
> # nvcamera_daemon and argus_daemon have hard-coded path for this
> install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> ln -sf ${libdir}/libEGL.so.1.0.0
> ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
> }
> PACKAGE_ARCH = "${MACHINE_ARCH}"
> FILES_libgles1-mesa += "\
> ${libdir}/libGLESv1* \
> "
> FILES_libgles2-mesa += "\
> ${libdir}/libGLESv2* \
> "
> FILES_libegl-mesa += "\
> ${libdir}/libEGL* \
> ${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
> "
> FILES_libgl-mesa += "\
> ${libdir}/libGL.* \
> ${libdir}/libGLX* \
> ${libdir}/libGLdispatch.so* \
> ${libdir}/libnvidia-glsi.so.28.2.1 \
> ${libdir}/libnvbuf_utils.so* \
> ${libdir}/libnvddk_vic.so  \
> ${libdir}/libnvddk_2d_v2.so \
> "
> INSANE_SKIP_${PN} = "already-stripped"
> INSANE_SKIP_libegl-mesa = "ldflags dev-so"
> INSANE_SKIP_libgles1-mesa = "ldflags dev-so"
> INSANE_SKIP_libgles2-mesa = "ldflags"
> INSANE_SKIP_libgl-mesa = "ldflags dev-so textrel"
> PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
> read_subpackage_metadata () {
> }
>
>
> This is as Richard suggested:
>
> DESCRIPTION = "Tegra replacements for mesa libraries"
>
> require recipes-bsp/tegra-binaries/tegra-glvnd.inc
>
> RDEPENDS_libgl-tegra = "tegra-lib-common libegl-tegra 

Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

[Ricardo Ribalda Delgado]

This is my approach (which is not more than a horrible hack)

DESCRIPTION = "Tegra replacements for mesa libraries"
require recipes-bsp/tegra-binaries/tegra-glvnd.inc
RDEPENDS_libgl-mesa = "tegra-lib-common libegl-mesa libxcb-glx
libxxf86vm libxdamage libxcb-xfixes"
RDEPENDS_libegl-mesa = "zlib libxcb-xfixes libxcb-present libdrm
libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
libx11 libx11-xcb"
RDEPENDS_libgles2-mesa = "libdrm libglapi"
RDEPENDS_libgles1-mesa = "libdrm libglapi"
RPROVIDES_libgl-mesa += "gl-proprietary libgl"
RPROVIDES_libegl-mesa += "libegl"
RPROVIDES_libgles2-mesa += "libgles2"
RPROVIDES_libgles1-mesa += "libgles1"
PV = "${L4T_RELEASE}"
PE = "5"
PACKAGES = "libgl-mesa libegl-mesa libgles2-mesa libgles1-mesa"
L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
do_unpack_append() {
bb.build.exec_func("unpack_l4t_tar", d)
}
unpack_l4t_tar() {
install -d ${L4T_GLVND_DIR}
tar -C ${L4T_GLVND_DIR} -x -f \
${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
usr/lib/aarch64-linux-gnu/tegra \
usr/lib/aarch64-linux-gnu/tegra-egl
}
do_compile[noexec] = "1"
PACKAGEFUNCS_append = " rm_pkgdata_runtime"
rm_pkgdata_runtime() {
rm -rf ${WORKDIR}/pkgdata/runtime/*
rm -rf ${WORKDIR}/pkgdata/shlibs2/*
}
do_install() {
install -d ${D}${libdir}
# Install NVIDIA mesa libraries (libglvnd)
install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
${D}${libdir}/libGLESv1_CM.so.1.1.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
${D}${libdir}/libGLESv2.so.2.0.0
ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
# Install extra NVIDIA libglvnd libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
# Install extra EGL NVIDIA libraries
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
# Install extra GL NVIDIA libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
# Install libraries dependent on libglvnd libs
install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
# nvcamera_daemon and argus_daemon have hard-coded path for this
install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
ln -sf ${libdir}/libEGL.so.1.0.0
${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
}
PACKAGE_ARCH = "${MACHINE_ARCH}"
FILES_libgles1-mesa += "\
${libdir}/libGLESv1* \
"
FILES_libgles2-mesa += "\
${libdir}/libGLESv2* \
"
FILES_libegl-mesa += "\
${libdir}/libEGL* \
${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
"
FILES_libgl-mesa += "\
${libdir}/libGL.* \
${libdir}/libGLX* \
${libdir}/libGLdispatch.so* \
${libdir}/libnvidia-glsi.so.28.2.1 \
${libdir}/libnvbuf_utils.so* \
${libdir}/libnvddk_vic.so  \
${libdir}/libnvddk_2d_v2.so \
"
INSANE_SKIP_${PN} = "already-stripped"
INSANE_SKIP_libegl-mesa = "ldflags dev-so"
INSANE_SKIP_libgles1-mesa = "ldflags dev-so"
INSANE_SKIP_libgles2-mesa = "ldflags"
INSANE_SKIP_libgl-mesa = "ldflags dev-so textrel"
PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
read_subpackage_metadata () {
}


This is as Richard suggested:

DESCRIPTION = "Tegra replacements for mesa libraries"

require recipes-bsp/tegra-binaries/tegra-glvnd.inc

RDEPENDS_libgl-tegra = "tegra-lib-common libegl-tegra libxcb-glx
libxxf86vm libxdamage libxcb-xfixes"
RDEPENDS_libegl-tegra = "zlib libxcb-xfixes libxcb-present libdrm
libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
libx11 libx11-xcb"
RDEPENDS_libgles2-tegra = "libdrm libglapi"
RDEPENDS_libgles1-tegra = "libdrm libglapi"

PV = "${L4T_RELEASE}"
PE = "5"

PACKAGES = "libgl-tegra libegl-tegra libgles2-tegra 

Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

[Burton, Ross]

That is horrible and they should be ashamed.  Can you share the
complete recipe, as this *should* be a fairly trivial switcharoony.

Ross

On Tue, 5 Mar 2019 at 11:00, Ricardo Ribalda Delgado
 wrote:
>
> HI Ross
> On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross  wrote:
> >
> > Does they literally just provide a libgl.so and no headers, etc?
>
> It provides:
>
> /usr/lib/libGL.so.1.2.0
> /usr/lib/libGL.so.1
>
>
> >
> > Ross
> >
> > On Fri, 1 Mar 2019 at 11:29, Ricardo Ribalda Delgado
> >  wrote:
> > >
> > > Hello
> > >
> > > I have a build system that supports some aarch64 machines. For most of
> > > the them, the only difference is the kernel configuration, kernel
> > > version.
> > >
> > > I am using multiconfig on my build server and the build goes really
> > > fast thanks to all the shared binaries/artifacts.
> > >
> > > But I have a problem adding a new machine. This machine is also
> > > aarch64, with a special kernel (nothing new here), but in this case
> > > the vendor provides a binary .so for libgl that is required to get
> > > hardware acceleation.
> > >
> > > I could .bbappend mesa and on the installation part replace libgl with
> > > the new .so. But then everything that depends on mesa needs to be
> > > rebuilt for that machine and I could not use multiconfig.
> > >
> > > Instead I have created a new recipe: mesa-gl-replace.bb that has the
> > > file. This breakes completely the design of OE, but works.
> > >
> > > Some snipsets of the "magic" to make it work:
> > >
> > > #Force that the version is allways higher than the one from mesa:
> > > PE = "5"
> > >
> > > #Rprovide the same as mesa
> > > RPROVIDES_libgl-mesa += "libgl"
> > >
> > > #Do not overwrite pkgdata of mesa
> > > PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> > > rm_pkgdata_runtime() {
> > > rm -rf ${WORKDIR}/pkgdata/runtime/*
> > > rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> > > }
> > >
> > > #Keep this on machine
> > > PACKAGE_ARCH = "${MACHINE_ARCH}"
> > >
> > > #Make sure we are not saved as providers for libgl
> > > PRIVATE_LIBS = "libGL.so.1"
> > >
> > > #Avoid sanity checks
> > > read_subpackage_metadata () {
> > > }
> > >
> > >
> > > If your eyes have not fallen as this point, this means you have a lot
> > > of tolerance for crappy code, congrats :)
> > >
> > > Now the question. Is there a better way to do this?
> > >
> > > PS: I already tried and failed with update_alternatives
> > >
> > >
> > > Best regards!
> > >
> > >
> > > --
> > > Ricardo Ribalda
> > > --
> > > ___
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

[Ricardo Ribalda Delgado]

HI Ross
On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross  wrote:
>
> Does they literally just provide a libgl.so and no headers, etc?

It provides:

/usr/lib/libGL.so.1.2.0
/usr/lib/libGL.so.1


>
> Ross
>
> On Fri, 1 Mar 2019 at 11:29, Ricardo Ribalda Delgado
>  wrote:
> >
> > Hello
> >
> > I have a build system that supports some aarch64 machines. For most of
> > the them, the only difference is the kernel configuration, kernel
> > version.
> >
> > I am using multiconfig on my build server and the build goes really
> > fast thanks to all the shared binaries/artifacts.
> >
> > But I have a problem adding a new machine. This machine is also
> > aarch64, with a special kernel (nothing new here), but in this case
> > the vendor provides a binary .so for libgl that is required to get
> > hardware acceleation.
> >
> > I could .bbappend mesa and on the installation part replace libgl with
> > the new .so. But then everything that depends on mesa needs to be
> > rebuilt for that machine and I could not use multiconfig.
> >
> > Instead I have created a new recipe: mesa-gl-replace.bb that has the
> > file. This breakes completely the design of OE, but works.
> >
> > Some snipsets of the "magic" to make it work:
> >
> > #Force that the version is allways higher than the one from mesa:
> > PE = "5"
> >
> > #Rprovide the same as mesa
> > RPROVIDES_libgl-mesa += "libgl"
> >
> > #Do not overwrite pkgdata of mesa
> > PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> > rm_pkgdata_runtime() {
> > rm -rf ${WORKDIR}/pkgdata/runtime/*
> > rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> > }
> >
> > #Keep this on machine
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > #Make sure we are not saved as providers for libgl
> > PRIVATE_LIBS = "libGL.so.1"
> >
> > #Avoid sanity checks
> > read_subpackage_metadata () {
> > }
> >
> >
> > If your eyes have not fallen as this point, this means you have a lot
> > of tolerance for crappy code, congrats :)
> >
> > Now the question. Is there a better way to do this?
> >
> > PS: I already tried and failed with update_alternatives
> >
> >
> > Best regards!
> >
> >
> > --
> > Ricardo Ribalda
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

[Burton, Ross]

Does they literally just provide a libgl.so and no headers, etc?

Ross

On Fri, 1 Mar 2019 at 11:29, Ricardo Ribalda Delgado
 wrote:
>
> Hello
>
> I have a build system that supports some aarch64 machines. For most of
> the them, the only difference is the kernel configuration, kernel
> version.
>
> I am using multiconfig on my build server and the build goes really
> fast thanks to all the shared binaries/artifacts.
>
> But I have a problem adding a new machine. This machine is also
> aarch64, with a special kernel (nothing new here), but in this case
> the vendor provides a binary .so for libgl that is required to get
> hardware acceleation.
>
> I could .bbappend mesa and on the installation part replace libgl with
> the new .so. But then everything that depends on mesa needs to be
> rebuilt for that machine and I could not use multiconfig.
>
> Instead I have created a new recipe: mesa-gl-replace.bb that has the
> file. This breakes completely the design of OE, but works.
>
> Some snipsets of the "magic" to make it work:
>
> #Force that the version is allways higher than the one from mesa:
> PE = "5"
>
> #Rprovide the same as mesa
> RPROVIDES_libgl-mesa += "libgl"
>
> #Do not overwrite pkgdata of mesa
> PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> rm_pkgdata_runtime() {
> rm -rf ${WORKDIR}/pkgdata/runtime/*
> rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> }
>
> #Keep this on machine
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> #Make sure we are not saved as providers for libgl
> PRIVATE_LIBS = "libGL.so.1"
>
> #Avoid sanity checks
> read_subpackage_metadata () {
> }
>
>
> If your eyes have not fallen as this point, this means you have a lot
> of tolerance for crappy code, congrats :)
>
> Now the question. Is there a better way to do this?
>
> PS: I already tried and failed with update_alternatives
>
>
> Best regards!
>
>
> --
> Ricardo Ribalda
> --
> ___
> 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] Two recipes providing the same .so... How it should not be done :)

[Ricardo Ribalda Delgado]

Epoch is set to 5, so that should not be the issue

PV = "${L4T_RELEASE}"
PE = "5"

Thanks

On Tue, Mar 5, 2019 at 10:37 AM Richard Purdie
 wrote:
>
> On Tue, 2019-03-05 at 09:27 +0100, Ricardo Ribalda Delgado wrote:
> > Hi Richard,
> >
> > Thanks for your reply!
> >
> > I tried with the following:
> >
> > INSANE_SKIP_${PN} = "already-stripped"
> > INSANE_SKIP_libegl-tegra = "ldflags dev-so"
> > INSANE_SKIP_libgles1-tegra = "ldflags dev-so"
> > INSANE_SKIP_libgles2-tegra = "ldflags"
> > INSANE_SKIP_libgl-tegra = "ldflags dev-so textrel"
> >
> > RREPLACES_libgl-tegra = "libgl-mesa"
> > RREPLACES_libegl-tegra = "libegl-mesa"
> > RREPLACES_libgles1-tegra = "libgles1-mesa"
> > RREPLACES_libgles2-tegra = "libgles2-mesa"
> >
> > RCONFLICTS_libgl-tegra = "libgl-mesa"
> > RCONFLICTS_libegl-tegra = "libegl-mesa"
> > RCONFLICTS_libgles1-tegra = "libgles1-mesa"
> > RCONFLICTS_libgles2-tegra = "libgles2-mesa"
> >
> > RPROVIDES_libgl-tegra += "gl-proprietary libgl libgl-mesa"
> > RPROVIDES_libegl-tegra += "libegl libegl-mesa"
> > RPROVIDES_libgles2-tegra += "libgles2 libgles2-tegra"
> > RPROVIDES_libgles1-tegra += "libgles1 libgles1-tegra"
> >
> > But then do_rootfs fails:
> >
> > The following packages have unmet dependencies:
> >  mesa-demos : Depends: libegl-mesa (>= 18.3.4+git0+b26488dead) but it
> > is not going to be installed
> >   Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it
> > is not going to be installed
> >  qv4l2 : Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it is
> > not
> > going to be installed
> >  Depends: qtbase (>= 5.11.1+git0+74305ba470) but it is not
> > going to be installed
> >
> >
> > I am forcing the installation of libgl-tegra by making:
> >
> > XSERVER += "gl-proprietary"
> >
> > What am I doing wrong :)
>
> I'd forgotten that things have hard version requirements in some of
> these dependencies :(
>
> You'd probably need to make sure your recipe has a version (or epoch,
> PE may be easier) higher than the original recipe? I think that is what
> the package manager is saying in the error above.
>
> Cheers,
>
> Richard
>


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

Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

[Richard Purdie]

On Tue, 2019-03-05 at 09:27 +0100, Ricardo Ribalda Delgado wrote:
> Hi Richard,
> 
> Thanks for your reply!
> 
> I tried with the following:
> 
> INSANE_SKIP_${PN} = "already-stripped"
> INSANE_SKIP_libegl-tegra = "ldflags dev-so"
> INSANE_SKIP_libgles1-tegra = "ldflags dev-so"
> INSANE_SKIP_libgles2-tegra = "ldflags"
> INSANE_SKIP_libgl-tegra = "ldflags dev-so textrel"
> 
> RREPLACES_libgl-tegra = "libgl-mesa"
> RREPLACES_libegl-tegra = "libegl-mesa"
> RREPLACES_libgles1-tegra = "libgles1-mesa"
> RREPLACES_libgles2-tegra = "libgles2-mesa"
> 
> RCONFLICTS_libgl-tegra = "libgl-mesa"
> RCONFLICTS_libegl-tegra = "libegl-mesa"
> RCONFLICTS_libgles1-tegra = "libgles1-mesa"
> RCONFLICTS_libgles2-tegra = "libgles2-mesa"
> 
> RPROVIDES_libgl-tegra += "gl-proprietary libgl libgl-mesa"
> RPROVIDES_libegl-tegra += "libegl libegl-mesa"
> RPROVIDES_libgles2-tegra += "libgles2 libgles2-tegra"
> RPROVIDES_libgles1-tegra += "libgles1 libgles1-tegra"
> 
> But then do_rootfs fails:
> 
> The following packages have unmet dependencies:
>  mesa-demos : Depends: libegl-mesa (>= 18.3.4+git0+b26488dead) but it
> is not going to be installed
>   Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it
> is not going to be installed
>  qv4l2 : Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it is
> not
> going to be installed
>  Depends: qtbase (>= 5.11.1+git0+74305ba470) but it is not
> going to be installed
> 
> 
> I am forcing the installation of libgl-tegra by making:
> 
> XSERVER += "gl-proprietary"
> 
> What am I doing wrong :)

I'd forgotten that things have hard version requirements in some of
these dependencies :(

You'd probably need to make sure your recipe has a version (or epoch,
PE may be easier) higher than the original recipe? I think that is what
the package manager is saying in the error above.

Cheers,

Richard

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

Re: [OE-core] [PATCH 0/4] Improve logger setup in devtool/recipetool/scriptutils

[Richard Purdie]

On Tue, 2019-03-05 at 16:50 +1300, Paul Eggleton wrote:
> On Tuesday, 5 March 2019 10:36:07 AM NZDT Christopher Larson wrote:
> > From: Christopher Larson 
> > 
> > This improves logger setup in devtool and recipetool to send ERRORs
> > to 
> stderr,
> > the way bitbake itself does, and also sends WARNINGs there, as
> > those are
> > essentially out of band as well. This makes it easier to script
> > with devtool
> > and recipetool, as any *real* subcommand output can be more easily
> > captured
> > without having to manually filter out the cruft.
> > 
> > The following changes since commit
> > b11725db2d5549dc45d8ae36fbf94a5c8e342d69:
> > 
> >   xserver-xorg: Fix build errors with clang (2019-03-04 14:26:41
> > +)
> > 
> > are available in the Git repository at:
> > 
> >   g...@github.com:kergoth/openembedded-core scriptutils-log-
> > improvements
> > 
> > for you to fetch changes up to
> > c4f37568236d2e3d8c40d57399d0b275ad5b7c8b:
> > 
> >   oe.scriptutils: also send WARNING to stderr (2019-03-04 21:31:00
> > +)
> > 
> > 
> > Christopher Larson (4):
> >   oe.scriptutils: enable color in a more flexible way
> >   oe.scriptutils: add logger_setup_filters
> >   recipetool, devtool: set up the logging filters
> >   oe.scriptutils: also send WARNING to stderr
> > 
> 
> All of these look good to me.
> 
> Acked-by: Paul Eggleton 

Unfortunately there were a couple of issues on the autobuilder in the
devtool selftests with these applied:

https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/297

Cheers,

Richard


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

Re: [OE-core] [PATCH] send-error-report: Use https instead of http protocol

[Robert Yang]

Hi RP,

I've sent a patch to fix for python3:

https://lists.yoctoproject.org/pipermail/yocto/2019-March/044387.html

And CC-ed michael.g.w...@intel.com, I assumed that he is the maintainer,
but seems that the email is not valid any more.

I think that we have more work to do with error report web, e.g.:
- The 'Similar' tag on the web isn't correct, it doesn't calculate correctly

- Sometimes, there is an error like:
  File "/buildarea/lyang1/error-report-web/Post/parser.py", line 101, in parse
num_similar_errors = f.get_similar_fails_count()
UnboundLocalError: local variable 'f' referenced before assignment

- We can make report-error.bbclass to catch more errors such as NoProvider
  errors, Parse errors, and so on.

I'd like to maintain it if it has no maintainers.

// Robert

On 3/4/19 6:33 PM, Robert Yang wrote:



On 3/4/19 6:26 PM, Richard Purdie wrote:

On Mon, 2019-03-04 at 18:02 +0800, Robert Yang wrote:

Hi RP,

On 3/4/19 5:23 PM, Richard Purdie wrote:

On Mon, 2019-03-04 at 15:50 +0800, Robert Yang wrote:

Hi Khem,

We have an internal error web server, this patch breaks it:

You're accessing the development server over HTTPS, but it only
supports HTTP

So I tried to use runsslserver, but it doesn't work either since
the
host is
Ubuntu 14.04 (python 2.7.6):

$ python manage.py runsslserver

[snip]
   ssl_version=ssl.PROTOCOL_TLSv1_2,
AttributeError: 'module' object has no attribute
'PROTOCOL_TLSv1_2'

This is because python is old.

I think that make it default to https would make the server
harder to
set up,
so is it possible to:

* Make it default to http, and add an option such as --https (or
--
ssl) for https

Or:

* Add an option such as --no-ssl to make it use http.

I prefer the first one since https server is harder to setup than
http in django. I can work on it if no objections.


At this point the project does require python3 so python2 being old
shouldn't be a reason to be changing this.


The python3 + error-report-web doesn't work for me:

$ python3 manage.py runserver ip:8000

And when I tried to access http://128.224.156.132:8000, it raised
errors:

error-report-web/Post/views.py", line 16, in 
  from parser import Parser
ImportError: cannot import name 'Parser'

So I use python 2 for it. I thought that it didn't support python3,
or didn't
test well.


Fixing it to work with python3 would be the preferred option...


Sounds good, I will work on it.

// Robert



Cheers,

Richard



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

Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

[Ricardo Ribalda Delgado]

Hi Richard,

Thanks for your reply!

I tried with the following:

INSANE_SKIP_${PN} = "already-stripped"
INSANE_SKIP_libegl-tegra = "ldflags dev-so"
INSANE_SKIP_libgles1-tegra = "ldflags dev-so"
INSANE_SKIP_libgles2-tegra = "ldflags"
INSANE_SKIP_libgl-tegra = "ldflags dev-so textrel"

RREPLACES_libgl-tegra = "libgl-mesa"
RREPLACES_libegl-tegra = "libegl-mesa"
RREPLACES_libgles1-tegra = "libgles1-mesa"
RREPLACES_libgles2-tegra = "libgles2-mesa"

RCONFLICTS_libgl-tegra = "libgl-mesa"
RCONFLICTS_libegl-tegra = "libegl-mesa"
RCONFLICTS_libgles1-tegra = "libgles1-mesa"
RCONFLICTS_libgles2-tegra = "libgles2-mesa"

RPROVIDES_libgl-tegra += "gl-proprietary libgl libgl-mesa"
RPROVIDES_libegl-tegra += "libegl libegl-mesa"
RPROVIDES_libgles2-tegra += "libgles2 libgles2-tegra"
RPROVIDES_libgles1-tegra += "libgles1 libgles1-tegra"

But then do_rootfs fails:

The following packages have unmet dependencies:
 mesa-demos : Depends: libegl-mesa (>= 18.3.4+git0+b26488dead) but it
is not going to be installed
  Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it
is not going to be installed
 qv4l2 : Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it is not
going to be installed
 Depends: qtbase (>= 5.11.1+git0+74305ba470) but it is not
going to be installed


I am forcing the installation of libgl-tegra by making:

XSERVER += "gl-proprietary"

What am I doing wrong :)

Thanks!

On Sat, Mar 2, 2019 at 1:21 PM Richard Purdie
 wrote:
>
> On Fri, 2019-03-01 at 12:28 +0100, Ricardo Ribalda Delgado wrote:
> > Hello
> >
> > I have a build system that supports some aarch64 machines. For most
> > of
> > the them, the only difference is the kernel configuration, kernel
> > version.
> >
> > I am using multiconfig on my build server and the build goes really
> > fast thanks to all the shared binaries/artifacts.
> >
> > But I have a problem adding a new machine. This machine is also
> > aarch64, with a special kernel (nothing new here), but in this case
> > the vendor provides a binary .so for libgl that is required to get
> > hardware acceleation.
> >
> > I could .bbappend mesa and on the installation part replace libgl
> > with
> > the new .so. But then everything that depends on mesa needs to be
> > rebuilt for that machine and I could not use multiconfig.
> >
> > Instead I have created a new recipe: mesa-gl-replace.bb that has the
> > file. This breakes completely the design of OE, but works.
> >
> > Some snipsets of the "magic" to make it work:
> >
> > #Force that the version is allways higher than the one from mesa:
> > PE = "5"
> >
> > #Rprovide the same as mesa
> > RPROVIDES_libgl-mesa += "libgl"
> >
> > #Do not overwrite pkgdata of mesa
> > PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> > rm_pkgdata_runtime() {
> > rm -rf ${WORKDIR}/pkgdata/runtime/*
> > rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> > }
> >
> > #Keep this on machine
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > #Make sure we are not saved as providers for libgl
> > PRIVATE_LIBS = "libGL.so.1"
> >
> > #Avoid sanity checks
> > read_subpackage_metadata () {
> > }
> >
> >
> > If your eyes have not fallen as this point, this means you have a lot
> > of tolerance for crappy code, congrats :)
> >
> > Now the question. Is there a better way to do this?
>
> I'd probably let mesa build as normal but then add a recipe which
> RRPROVIDES, RREPLACES and RCONFLICTS with the specific mesa package you
> want to replace. It would create and equivalent package with the right
> contents and make it machine specific.
>
> There should be more variables like PRIVATE_LIBS which stop you having
> to use the more horrible hacks (INSANE_SKIP_*?).
>
> You might then only have the issue of ensuring this machine specific
> package gets installed into the images which need GL (or just install
> it in all images for that machine).
>
> Cheers,
>
> Richard
>


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