Re: [OE-core] [PATCH v2] staging.bbclass: Fix wrong library paths in sysroot_strip

[Junling Zheng]

ping...

On 2019/11/16 22:12, Junling Zheng wrote:
> Do not reset libdir and base_libdir in sysroot_strip, and just pass crude
> paths as they will be reset later in strip_execs.
> 
> Signed-off-by: Junling Zheng 
> ---
> v2:
>  - Fix undefined variable error.
> 
>  meta/classes/staging.bbclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
> index cca0b7e0d6..7e108950f5 100644
> --- a/meta/classes/staging.bbclass
> +++ b/meta/classes/staging.bbclass
> @@ -75,8 +75,8 @@ python sysroot_strip () {
>  
>  dstdir = d.getVar('SYSROOT_DESTDIR')
>  pn = d.getVar('PN')
> -libdir = os.path.abspath(dstdir + os.sep + d.getVar("libdir"))
> -base_libdir = os.path.abspath(dstdir + os.sep + d.getVar("base_libdir"))
> +libdir = d.getVar("libdir")
> +base_libdir = d.getVar("base_libdir")
>  qa_already_stripped = 'already-stripped' in (d.getVar('INSANE_SKIP_' + 
> pn) or "").split()
>  strip_cmd = d.getVar("STRIP")
>  
> 


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

[OE-core] ✗ patchtest: failure for cronie:upgrade 1.5.4 -> 1.5.5 (rev2)

[Patchwork]

== Series Details ==

Series: cronie:upgrade 1.5.4 -> 1.5.5 (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/21308/
State : failure

== Summary ==


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



* Patchkexec-tools: upgrade 2.0.19 -> 2.0.20
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] ✗ patchtest: failure for cronie:upgrade 1.5.4 -> 1.5.5

[Patchwork]

== Series Details ==

Series: cronie:upgrade 1.5.4 -> 1.5.5
Revision: 1
URL   : https://patchwork.openembedded.org/series/21308/
State : failure

== Summary ==


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



* Patchcronie:upgrade 1.5.4 -> 1.5.5
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

Re: [OE-core] [PATCH] cronie:upgrade 1.5.4 -> 1.5.5

[Mittal, Anuj]

Has this been tested with musl? I think would fail because anacron has
now been enabled by default [1] which in turn needs obstack [2].

[1] 
https://github.com/cronie-crond/cronie/commit/a8920856869a4682ce2300368da623fc86645c7a

[2] 
https://github.com/cronie-crond/cronie/blob/master/anacron/readtab.c

Also the anacron option should probably be converted to a PACKAGECONFIG
since we didn't have --enable-anacron.

Thanks,

Anuj

On Fri, 2019-11-22 at 02:51 -0800, Wang Mingyu wrote:
> ---
>  meta/recipes-extended/cronie/{cronie_1.5.4.bb => cronie_1.5.5.bb} |
> 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>  rename meta/recipes-extended/cronie/{cronie_1.5.4.bb =>
> cronie_1.5.5.bb} (94%)
> 
> diff --git a/meta/recipes-extended/cronie/cronie_1.5.4.bb
> b/meta/recipes-extended/cronie/cronie_1.5.5.bb
> similarity index 94%
> rename from meta/recipes-extended/cronie/cronie_1.5.4.bb
> rename to meta/recipes-extended/cronie/cronie_1.5.5.bb
> index d35c667..b327381 100644
> --- a/meta/recipes-extended/cronie/cronie_1.5.4.bb
> +++ b/meta/recipes-extended/cronie/cronie_1.5.5.bb
> @@ -16,7 +16,7 @@ SECTION = "utils"
>  
>  UPSTREAM_CHECK_URI = "
> https://github.com/cronie-crond/${BPN}/releases/;
>  
> -SRC_URI = "
> https://github.com/cronie-crond/cronie/releases/download/cronie-${PV}-final/cronie-${PV}.tar.gz
> \
> +SRC_URI = "
> https://github.com/cronie-crond/cronie/releases/download/cronie-${PV}/cronie-${PV}.tar.gz
> \
> file://crond.init \
> file://crontab \
> file://crond.service \
> @@ -25,8 +25,8 @@ SRC_URI = "
> https://github.com/cronie-crond/cronie/releases/download/cronie-${PV}
>  PAM_SRC_URI = "file://crond_pam_config.patch"
>  PAM_DEPS = "libpam libpam-runtime pam-plugin-access pam-plugin-
> loginuid"
>  
> -SRC_URI[md5sum] = "20233b96997e17a142e1fbe0d7ce8223"
> -SRC_URI[sha256sum] =
> "af8970559cad4262f8ffd7ec72abf682d2dcce04fdfb8f206a71d96566aba882"
> +SRC_URI[md5sum] = "351a37d0b5bd0144816724b4482747ad"
> +SRC_URI[sha256sum] =
> "be34c79505e5544323281854744b9955ff16b160ee569f9df7c0dddae5720eac"
>  
>  inherit autotools update-rc.d useradd systemd
>  
> -- 
> 2.7.4
> 
> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] kexec-tools: upgrade 2.0.19 -> 2.0.20

[Wang Mingyu]

---
 .../kexec/{kexec-tools_2.0.19.bb => kexec-tools_2.0.20.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-kernel/kexec/{kexec-tools_2.0.19.bb => 
kexec-tools_2.0.20.bb} (95%)

diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.19.bb 
b/meta/recipes-kernel/kexec/kexec-tools_2.0.20.bb
similarity index 95%
rename from meta/recipes-kernel/kexec/kexec-tools_2.0.19.bb
rename to meta/recipes-kernel/kexec/kexec-tools_2.0.20.bb
index c3f7435..b79e33b 100644
--- a/meta/recipes-kernel/kexec/kexec-tools_2.0.19.bb
+++ b/meta/recipes-kernel/kexec/kexec-tools_2.0.20.bb
@@ -21,8 +21,8 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/kernel/kexec/kexec-tools-${PV}.tar.gz
 file://0006-kexec-arm-undefine-__NR_kexec_file_load-for-arm.patch \
 "
 
-SRC_URI[md5sum] = "052458f0a35c2a3b0d2302caa3318e9f"
-SRC_URI[sha256sum] = 
"913c8dee918e5855a4ba60d609371390978144b4c8d15d6446ca0057b7bc5e58"
+SRC_URI[md5sum] = "46724b67f32501c5d3e778161347cad9"
+SRC_URI[sha256sum] = 
"cb16d79818e0c9de3bb3e33ede5677c34a1d28c646379c7ab44e0faa3eb57a16"
 
 inherit autotools update-rc.d systemd
 
-- 
2.7.4



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

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

[Wang Mingyu]

---
 meta/recipes-extended/cronie/{cronie_1.5.4.bb => cronie_1.5.5.bb} | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-extended/cronie/{cronie_1.5.4.bb => cronie_1.5.5.bb} (94%)

diff --git a/meta/recipes-extended/cronie/cronie_1.5.4.bb 
b/meta/recipes-extended/cronie/cronie_1.5.5.bb
similarity index 94%
rename from meta/recipes-extended/cronie/cronie_1.5.4.bb
rename to meta/recipes-extended/cronie/cronie_1.5.5.bb
index d35c667..b327381 100644
--- a/meta/recipes-extended/cronie/cronie_1.5.4.bb
+++ b/meta/recipes-extended/cronie/cronie_1.5.5.bb
@@ -16,7 +16,7 @@ SECTION = "utils"
 
 UPSTREAM_CHECK_URI = "https://github.com/cronie-crond/${BPN}/releases/;
 
-SRC_URI = 
"https://github.com/cronie-crond/cronie/releases/download/cronie-${PV}-final/cronie-${PV}.tar.gz
 \
+SRC_URI = 
"https://github.com/cronie-crond/cronie/releases/download/cronie-${PV}/cronie-${PV}.tar.gz
 \
file://crond.init \
file://crontab \
file://crond.service \
@@ -25,8 +25,8 @@ SRC_URI = 
"https://github.com/cronie-crond/cronie/releases/download/cronie-${PV}
 PAM_SRC_URI = "file://crond_pam_config.patch"
 PAM_DEPS = "libpam libpam-runtime pam-plugin-access pam-plugin-loginuid"
 
-SRC_URI[md5sum] = "20233b96997e17a142e1fbe0d7ce8223"
-SRC_URI[sha256sum] = 
"af8970559cad4262f8ffd7ec72abf682d2dcce04fdfb8f206a71d96566aba882"
+SRC_URI[md5sum] = "351a37d0b5bd0144816724b4482747ad"
+SRC_URI[sha256sum] = 
"be34c79505e5544323281854744b9955ff16b160ee569f9df7c0dddae5720eac"
 
 inherit autotools update-rc.d useradd systemd
 
-- 
2.7.4



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

[OE-core] [zeus][PATCH] bind: fix CVE-2019-6471 and CVE-2018-5743

[kai.kang]

From: Kai Kang 

Backport patches to fix CVE-2019-6471 and CVE-2018-5743 for bind.
CVE-2019-6471 is fixed by 0001-bind-fix-CVE-2019-6471.patch and the
other 6 patches are for CVE-2018-5743. And backport one more patch to
fix compile error on arm caused by these 6 commits.

(From OE-Core rev: 3c39d4158677b97253df63f23b74c3a9dd5539f6)

Signed-off-by: Kai Kang 
Signed-off-by: Richard Purdie 
---
 .../bind/0001-bind-fix-CVE-2019-6471.patch|  64 ++
 ...01-fix-enforcement-of-tcp-clients-v1.patch |  60 ++
 ...p-clients-could-still-be-exceeded-v2.patch | 670 +
 ...rence-counter-for-pipeline-groups-v3.patch | 278 ++
 ...accounting-and-client-mortality-chec.patch | 512 ++
 ...a-and-pipeline-refs-allow-special-ca.patch | 911 ++
 ...allowance-for-tcp-clients-interfaces.patch |  80 ++
 ...perations-in-bin-named-client.c-with.patch | 140 +++
 .../bind/bind_9.11.5-P4.bb|   8 +
 9 files changed, 2723 insertions(+)
 create mode 100644 
meta/recipes-connectivity/bind/bind/0001-bind-fix-CVE-2019-6471.patch
 create mode 100644 
meta/recipes-connectivity/bind/bind/0001-fix-enforcement-of-tcp-clients-v1.patch
 create mode 100644 
meta/recipes-connectivity/bind/bind/0002-tcp-clients-could-still-be-exceeded-v2.patch
 create mode 100644 
meta/recipes-connectivity/bind/bind/0003-use-reference-counter-for-pipeline-groups-v3.patch
 create mode 100644 
meta/recipes-connectivity/bind/bind/0004-better-tcpquota-accounting-and-client-mortality-chec.patch
 create mode 100644 
meta/recipes-connectivity/bind/bind/0005-refactor-tcpquota-and-pipeline-refs-allow-special-ca.patch
 create mode 100644 
meta/recipes-connectivity/bind/bind/0006-restore-allowance-for-tcp-clients-interfaces.patch
 create mode 100644 
meta/recipes-connectivity/bind/bind/0007-Replace-atomic-operations-in-bin-named-client.c-with.patch

diff --git 
a/meta/recipes-connectivity/bind/bind/0001-bind-fix-CVE-2019-6471.patch 
b/meta/recipes-connectivity/bind/bind/0001-bind-fix-CVE-2019-6471.patch
new file mode 100644
index 00..2fed99e1bb
--- /dev/null
+++ b/meta/recipes-connectivity/bind/bind/0001-bind-fix-CVE-2019-6471.patch
@@ -0,0 +1,64 @@
+Backport patch to fix CVE-2019-6471.
+
+Ref:
+https://security-tracker.debian.org/tracker/CVE-2019-6471
+
+CVE: CVE-2019-6471
+Upstream-Status: Backport 
[https://gitlab.isc.org/isc-projects/bind9/commit/3a9c7bb]
+
+Signed-off-by: Kai Kang 
+
+From 3a9c7bb80d4a609b86427406d9dd783199920b5b Mon Sep 17 00:00:00 2001
+From: Mark Andrews 
+Date: Tue, 19 Mar 2019 14:14:21 +1100
+Subject: [PATCH] move item_out test inside lock in dns_dispatch_getnext()
+
+(cherry picked from commit 60c42f849d520564ed42e5ed0ba46b4b69c07712)
+---
+ lib/dns/dispatch.c | 12 
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/lib/dns/dispatch.c b/lib/dns/dispatch.c
+index 408beda367..3278db4a07 100644
+--- a/lib/dns/dispatch.c
 b/lib/dns/dispatch.c
+@@ -134,7 +134,7 @@ struct dns_dispentry {
+   isc_task_t *task;
+   isc_taskaction_taction;
+   void   *arg;
+-  boolitem_out;
++  boolitem_out;
+   dispsocket_t*dispsocket;
+   ISC_LIST(dns_dispatchevent_t)   items;
+   ISC_LINK(dns_dispentry_t)   link;
+@@ -3422,13 +3422,14 @@ dns_dispatch_getnext(dns_dispentry_t *resp, 
dns_dispatchevent_t **sockevent) {
+   disp = resp->disp;
+   REQUIRE(VALID_DISPATCH(disp));
+ 
+-  REQUIRE(resp->item_out == true);
+-  resp->item_out = false;
+-
+   ev = *sockevent;
+   *sockevent = NULL;
+ 
+   LOCK(>lock);
++
++  REQUIRE(resp->item_out == true);
++  resp->item_out = false;
++
+   if (ev->buffer.base != NULL)
+   free_buffer(disp, ev->buffer.base, ev->buffer.length);
+   free_devent(disp, ev);
+@@ -3573,6 +3574,9 @@ dns_dispatch_removeresponse(dns_dispentry_t **resp,
+   isc_task_send(disp->task[0], >ctlevent);
+ }
+ 
++/*
++ * disp must be locked.
++ */
+ static void
+ do_cancel(dns_dispatch_t *disp) {
+   dns_dispatchevent_t *ev;
+-- 
+2.20.1
+
diff --git 
a/meta/recipes-connectivity/bind/bind/0001-fix-enforcement-of-tcp-clients-v1.patch
 
b/meta/recipes-connectivity/bind/bind/0001-fix-enforcement-of-tcp-clients-v1.patch
new file mode 100644
index 00..48ae125f84
--- /dev/null
+++ 
b/meta/recipes-connectivity/bind/bind/0001-fix-enforcement-of-tcp-clients-v1.patch
@@ -0,0 +1,60 @@
+Backport patch to fix CVE-2018-5743.
+
+Ref:
+https://security-tracker.debian.org/tracker/CVE-2018-5743
+
+CVE: CVE-2018-5743
+Upstream-Status: Backport 
[https://gitlab.isc.org/isc-projects/bind9/commit/ec2d50d]
+
+Signed-off-by: Kai Kang 
+
+From ec2d50da8d81814640e28593d912f4b96c7efece Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Witold=20Kr=C4=99cicki?= 
+Date: Thu, 3 Jan 2019 14:17:43 +0100
+Subject: [PATCH 1/6] fix enforcement of tcp-clients (v1)
+

Re: [OE-core] [PATCH] librsvg: Fix build reproducibility

[Khem Raj]

On Thu, Nov 21, 2019 at 5:40 PM Joshua Watt  wrote:
>
> On Thu, Nov 21, 2019 at 7:14 PM Khem Raj  wrote:
> >
> > On Thu, 2019-11-21 at 10:58 -0600, Joshua Watt wrote:
> > > librsvg was encoding the path to the build directory in order to find
> > > a
> > > font file for testing. This wouldn't work in OE anyway since the
> > > build
> > > directory isn't present at that exact location on the target, so
> > > remove
> > > the offending path to make the build reproducible.
> > >
> > > Signed-off-by: Joshua Watt 
> > > ---
> > >  .../0001-Remove-non-reproducible-SRCDIR.patch | 30
> > > +++
> > >  meta/recipes-gnome/librsvg/librsvg_2.40.20.bb |  1 +
> > >  2 files changed, 31 insertions(+)
> > >  create mode 100644 meta/recipes-gnome/librsvg/librsvg/0001-Remove-
> > > non-reproducible-SRCDIR.patch
> > >
> > > diff --git a/meta/recipes-gnome/librsvg/librsvg/0001-Remove-non-
> > > reproducible-SRCDIR.patch b/meta/recipes-gnome/librsvg/librsvg/0001-
> > > Remove-non-reproducible-SRCDIR.patch
> > > new file mode 100644
> > > index 000..75fc7f9d0b9
> > > --- /dev/null
> > > +++ b/meta/recipes-gnome/librsvg/librsvg/0001-Remove-non-
> > > reproducible-SRCDIR.patch
> > > @@ -0,0 +1,30 @@
> > > +From bea5156cd7e7122715b26c769c35928141a1da2c Mon Sep 17 00:00:00
> > > 2001
> > > +From: Joshua Watt 
> > > +Date: Mon, 18 Nov 2019 14:46:34 -0600
> > > +Subject: [PATCH] Remove non-reproducible SRCDIR
> > > +
> > > +Removes SRCDIR as the prefix for finding the test font. This
> > > wouldn't
> > > +work anyway, since that path is not present on the target.
> > > +
> > > +This patch is specific to OE, since it appears that this entire
> > > method
> > > +of testing was removed when upstream was re-written in rust
> > > +
> > > +Upstream-Status: Inappropriate [OE-specific, no longer present
> > > upstream]
> >
> > what replaced it ( just curious ), can we backport the fix that removed
> > it or made obsolete ?
>
> A significant portion of the library was re-written in rust. This code
> appears to be only for internal testing and wasn't preserved when it
> was re-written (at least I couldn't find it in my cursory inspection).
> We haven't been able to upgrade the library due to lack of rust
> support in oe-core.
>

ah thanks. perhaps librsvg should be moved to meta-gnome or other layer
which can depend on meta-rust. there are 3 recipes in oe-core which seem
to depend on it and they all can use packageconfig to use it.

> >
> > > +Signed-off-by: Joshua Watt 
> > > +---
> > > + rsvg-cairo-draw.c | 2 +-
> > > + 1 file changed, 1 insertion(+), 1 deletion(-)
> > > +
> > > +diff --git a/rsvg-cairo-draw.c b/rsvg-cairo-draw.c
> > > +index caa9104..cfb7ed2 100644
> > > +--- a/rsvg-cairo-draw.c
> > >  b/rsvg-cairo-draw.c
> > > +@@ -398,7 +398,7 @@ set_font_options_for_testing (PangoContext
> > > *context)
> > > + static void
> > > + create_font_config_for_testing (RsvgCairoRender *render)
> > > + {
> > > +-const char *font_path = SRCDIR
> > > "/tests/resources/LiberationSans-Regular.ttf";
> > > ++const char *font_path = "/tests/resources/LiberationSans-
> > > Regular.ttf";
> > > +
> > > + if (render->font_config_for_testing != NULL)
> > > + return;
> > > diff --git a/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> > > b/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> > > index 7f98127fd01..6dd0533a5de 100644
> > > --- a/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> > > +++ b/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> > > @@ -20,6 +20,7 @@ inherit gnomebase gtk-doc pixbufcache upstream-
> > > version-is-even gobject-introspec
> > >
> > >  SRC_URI += "file://gtk-option.patch \
> > >  file://0001-Auto-detect-Bsymbolic-fixes-configure-on-
> > > macOS.patch \
> > > +file://0001-Remove-non-reproducible-SRCDIR.patch \
> > >  "
> > >
> > >  SRC_URI[archive.md5sum] = "4949d313b0c5d9161a5c259104af5568"
> > > --
> > > 2.23.0
> > >
> >
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] librsvg: Fix build reproducibility

[Joshua Watt]

On Thu, Nov 21, 2019 at 7:14 PM Khem Raj  wrote:
>
> On Thu, 2019-11-21 at 10:58 -0600, Joshua Watt wrote:
> > librsvg was encoding the path to the build directory in order to find
> > a
> > font file for testing. This wouldn't work in OE anyway since the
> > build
> > directory isn't present at that exact location on the target, so
> > remove
> > the offending path to make the build reproducible.
> >
> > Signed-off-by: Joshua Watt 
> > ---
> >  .../0001-Remove-non-reproducible-SRCDIR.patch | 30
> > +++
> >  meta/recipes-gnome/librsvg/librsvg_2.40.20.bb |  1 +
> >  2 files changed, 31 insertions(+)
> >  create mode 100644 meta/recipes-gnome/librsvg/librsvg/0001-Remove-
> > non-reproducible-SRCDIR.patch
> >
> > diff --git a/meta/recipes-gnome/librsvg/librsvg/0001-Remove-non-
> > reproducible-SRCDIR.patch b/meta/recipes-gnome/librsvg/librsvg/0001-
> > Remove-non-reproducible-SRCDIR.patch
> > new file mode 100644
> > index 000..75fc7f9d0b9
> > --- /dev/null
> > +++ b/meta/recipes-gnome/librsvg/librsvg/0001-Remove-non-
> > reproducible-SRCDIR.patch
> > @@ -0,0 +1,30 @@
> > +From bea5156cd7e7122715b26c769c35928141a1da2c Mon Sep 17 00:00:00
> > 2001
> > +From: Joshua Watt 
> > +Date: Mon, 18 Nov 2019 14:46:34 -0600
> > +Subject: [PATCH] Remove non-reproducible SRCDIR
> > +
> > +Removes SRCDIR as the prefix for finding the test font. This
> > wouldn't
> > +work anyway, since that path is not present on the target.
> > +
> > +This patch is specific to OE, since it appears that this entire
> > method
> > +of testing was removed when upstream was re-written in rust
> > +
> > +Upstream-Status: Inappropriate [OE-specific, no longer present
> > upstream]
>
> what replaced it ( just curious ), can we backport the fix that removed
> it or made obsolete ?

A significant portion of the library was re-written in rust. This code
appears to be only for internal testing and wasn't preserved when it
was re-written (at least I couldn't find it in my cursory inspection).
We haven't been able to upgrade the library due to lack of rust
support in oe-core.

>
> > +Signed-off-by: Joshua Watt 
> > +---
> > + rsvg-cairo-draw.c | 2 +-
> > + 1 file changed, 1 insertion(+), 1 deletion(-)
> > +
> > +diff --git a/rsvg-cairo-draw.c b/rsvg-cairo-draw.c
> > +index caa9104..cfb7ed2 100644
> > +--- a/rsvg-cairo-draw.c
> >  b/rsvg-cairo-draw.c
> > +@@ -398,7 +398,7 @@ set_font_options_for_testing (PangoContext
> > *context)
> > + static void
> > + create_font_config_for_testing (RsvgCairoRender *render)
> > + {
> > +-const char *font_path = SRCDIR
> > "/tests/resources/LiberationSans-Regular.ttf";
> > ++const char *font_path = "/tests/resources/LiberationSans-
> > Regular.ttf";
> > +
> > + if (render->font_config_for_testing != NULL)
> > + return;
> > diff --git a/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> > b/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> > index 7f98127fd01..6dd0533a5de 100644
> > --- a/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> > +++ b/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> > @@ -20,6 +20,7 @@ inherit gnomebase gtk-doc pixbufcache upstream-
> > version-is-even gobject-introspec
> >
> >  SRC_URI += "file://gtk-option.patch \
> >  file://0001-Auto-detect-Bsymbolic-fixes-configure-on-
> > macOS.patch \
> > +file://0001-Remove-non-reproducible-SRCDIR.patch \
> >  "
> >
> >  SRC_URI[archive.md5sum] = "4949d313b0c5d9161a5c259104af5568"
> > --
> > 2.23.0
> >
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] librsvg: Fix build reproducibility

[Khem Raj]

On Thu, 2019-11-21 at 10:58 -0600, Joshua Watt wrote:
> librsvg was encoding the path to the build directory in order to find
> a
> font file for testing. This wouldn't work in OE anyway since the
> build
> directory isn't present at that exact location on the target, so
> remove
> the offending path to make the build reproducible.
> 
> Signed-off-by: Joshua Watt 
> ---
>  .../0001-Remove-non-reproducible-SRCDIR.patch | 30
> +++
>  meta/recipes-gnome/librsvg/librsvg_2.40.20.bb |  1 +
>  2 files changed, 31 insertions(+)
>  create mode 100644 meta/recipes-gnome/librsvg/librsvg/0001-Remove-
> non-reproducible-SRCDIR.patch
> 
> diff --git a/meta/recipes-gnome/librsvg/librsvg/0001-Remove-non-
> reproducible-SRCDIR.patch b/meta/recipes-gnome/librsvg/librsvg/0001-
> Remove-non-reproducible-SRCDIR.patch
> new file mode 100644
> index 000..75fc7f9d0b9
> --- /dev/null
> +++ b/meta/recipes-gnome/librsvg/librsvg/0001-Remove-non-
> reproducible-SRCDIR.patch
> @@ -0,0 +1,30 @@
> +From bea5156cd7e7122715b26c769c35928141a1da2c Mon Sep 17 00:00:00
> 2001
> +From: Joshua Watt 
> +Date: Mon, 18 Nov 2019 14:46:34 -0600
> +Subject: [PATCH] Remove non-reproducible SRCDIR
> +
> +Removes SRCDIR as the prefix for finding the test font. This
> wouldn't
> +work anyway, since that path is not present on the target.
> +
> +This patch is specific to OE, since it appears that this entire
> method
> +of testing was removed when upstream was re-written in rust
> +
> +Upstream-Status: Inappropriate [OE-specific, no longer present
> upstream]

what replaced it ( just curious ), can we backport the fix that removed
it or made obsolete ?

> +Signed-off-by: Joshua Watt 
> +---
> + rsvg-cairo-draw.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/rsvg-cairo-draw.c b/rsvg-cairo-draw.c
> +index caa9104..cfb7ed2 100644
> +--- a/rsvg-cairo-draw.c
>  b/rsvg-cairo-draw.c
> +@@ -398,7 +398,7 @@ set_font_options_for_testing (PangoContext
> *context)
> + static void
> + create_font_config_for_testing (RsvgCairoRender *render)
> + {
> +-const char *font_path = SRCDIR
> "/tests/resources/LiberationSans-Regular.ttf";
> ++const char *font_path = "/tests/resources/LiberationSans-
> Regular.ttf";
> + 
> + if (render->font_config_for_testing != NULL)
> + return;
> diff --git a/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> b/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> index 7f98127fd01..6dd0533a5de 100644
> --- a/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> +++ b/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
> @@ -20,6 +20,7 @@ inherit gnomebase gtk-doc pixbufcache upstream-
> version-is-even gobject-introspec
>  
>  SRC_URI += "file://gtk-option.patch \
>  file://0001-Auto-detect-Bsymbolic-fixes-configure-on-
> macOS.patch \
> +file://0001-Remove-non-reproducible-SRCDIR.patch \
>  "
>  
>  SRC_URI[archive.md5sum] = "4949d313b0c5d9161a5c259104af5568"
> -- 
> 2.23.0
> 

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

Re: [OE-core] How to backport openssl to Sumo

[Ross Burton]

On 21/11/2019 08:05, mikko.rap...@bmw.de wrote:

On Wed, Nov 20, 2019 at 03:53:14PM -0800, Andre McCurdy wrote:

But anyway, in all cases, the way to debug what's going on isn't to
try random recipe changes and then rebuild the final image. Instead
you should build your chosen version of openssl, look in the
packages-split directory to see which package includes the openssl
command line tool and then add that package to your image.


Or enable buildhistory, build openssl and/or image(s), cd build/buildhistory
and git grep for the binaries needed to find out which binary package
they belong to.


packages-split doesn't work with rm_work or where sstate was used. 
buildhistory needs to be enabled and you need to dig manually.


It's better to use the tools that come out of the box:

$ oe-pkgdata-util find-path /usr/bin/openssl
openssl-bin: /usr/bin/openssl

That's a glob search, so **/*.py will find all built packages that ship 
Python code for example.


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

Re: [OE-core] [PATCH] ghostscript: CVE-2019-14869

[Ross Burton]

On 21/11/2019 15:28, Stefan Ghinea wrote:

  file://CVE-2019-14811-0001.patch \
  file://CVE-2019-14817-0001.patch \
  file://CVE-2019-14817-0002.patch \
+file://CVE-2019-14869-0001.patch \
+
  "



Parsing recipes...ERROR: ParseError at 
/home/pokybuild/yocto-worker/qemux86-64/build/meta/recipes-extended/ghostscript/ghostscript_9.27.bb:32: 
unparsed line: 'SRC_URI_BASE = 
"https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs927/${BPN}-${PV}.tar.gz 
file://ghostscript-9.15-parallel-make.patch 
file://ghostscript-9.16-Werror-return-type.patch 
file://do-not-check-local-libpng-source.patch 
file://avoid-host-contamination.patch 
file://mkdir-p.patch file://CVE-2019-14811-0001.patch 
 file://CVE-2019-14817-0001.patch 
file://CVE-2019-14817-0002.patch 
file://CVE-2019-14869-0001.patch '


Please remember to test your patches.

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

Re: [OE-core] [PATCH 1/1] coreutils: add ptest

[Khem Raj]

On Thu, Nov 21, 2019 at 9:43 AM Trevor Gamblin
 wrote:
>
> From: Trevor Gamblin 
>
> coreutils has a large number of tests, (and potential RDEPENDS
> to support them), including tests added with the flags
> RUN_EXPENSIVE_TESTS and RUN_VERY_EXPENSIVE_TESTS that add
> significant run time for their coverage. The RUN_VERY_EXPENSIVE_TESTS
> option has been omitted from the run-ptest script to reduce
> some of this run time, even though this increases the SKIP count
> in the results. Also, the ptest directory for coreutils is given
> blanket permissions at runtime with chmod -R 777 to ensure that
> the user created for the tests will be able to run the test
> scripts and create the necessary files in the process.
>
> There is still room to improve the results of this ptest without
> the aforementioned additions. Of the tests marked SKIP, there
> are 30 tests that are currently counted as SKIP because they
> require root permissions, and another 21 that require membership
> in multiple user groups. It is important to know that coreutils
> has tests for both root and non-root users. Testing showed that
> 42 tests are skipped when running as root versus 30 when running
> as a non-root user, so the decision was made to run the suite as
> the latter.
>
> Finally, note that the ptest suite for coreutils has a short
> runtime on x86-64/kvm of approximately 4.5 minutes, in contrast
> to the arm64 runtime of ~70 minutes.
>
> Signed-off-by: Trevor Gamblin 
> ---
>  .../coreutils/coreutils/run-ptest | 17 +
>  meta/recipes-core/coreutils/coreutils_8.31.bb | 38 +++
>  2 files changed, 55 insertions(+)
>  create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest
>
> diff --git a/meta/recipes-core/coreutils/coreutils/run-ptest 
> b/meta/recipes-core/coreutils/coreutils/run-ptest
> new file mode 100755
> index 00..683fedee7a
> --- /dev/null
> +++ b/meta/recipes-core/coreutils/coreutils/run-ptest
> @@ -0,0 +1,17 @@
> +#!/bin/bash
> +
> +COREUTILSLIB=/usr/lib/coreutils

does this need to consider lib|lib64 care for libdir ?

> +LOG="${COREUTILSLIB}/ptest/coreutils_ptest_$(date +%Y%m%d-%H%M%S).log"
> +
> +addgroup usergroup1
> +adduser --ingroup usergroup1 tester
> +
> +su tester -c "make check-TESTS RUN_EXPENSIVE_TESTS=yes top_srcdir=. 
> srcdir=." | tee -a ${LOG}
> +deluser tester
> +delgroup usergroup1
> +
> +passed=`grep PASS ${LOG}|wc -l`
> +failed=`grep FAIL ${LOG}|wc -l`
> +skipped=`grep -E SKIP ${LOG}|wc -l`
> +all=$((passed + failed + skipped))
> +
> diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb 
> b/meta/recipes-core/coreutils/coreutils_8.31.bb
> index 57b2c1bdba..5ce2730048 100644
> --- a/meta/recipes-core/coreutils/coreutils_8.31.bb
> +++ b/meta/recipes-core/coreutils/coreutils_8.31.bb
> @@ -143,3 +143,41 @@ python __anonymous() {
>  }
>
>  BBCLASSEXTEND = "native nativesdk"
> +
> +inherit ptest
> +
> +FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> +
> +SRC_URI += "file://run-ptest"
> +RDEPENDS_${PN}-ptest += "bash findutils gawk gdb glibc libconvert-asn1-perl 
> liberror-perl libmodule-build-perl libtimedate-perl liburi-perl make perl 
> perl-module-file-stat python strace"
> +
> +do_install_ptest () {
> +   install -d ${D}${PTEST_PATH}/tests
> +   cp -r ${S}/tests/* ${D}${PTEST_PATH}/tests
> +   sed -i 's/ginstall/install/g'  `grep -R ginstall 
> ${D}${PTEST_PATH}/tests | awk -F: '{print $1}' | uniq`
> +   install -d ${D}${PTEST_PATH}/build-aux
> +   install ${S}/build-aux/test-driver ${D}${PTEST_PATH}/build-aux/
> +   cp ${B}/Makefile ${D}${PTEST_PATH}/
> +   cp ${S}/init.cfg ${D}${PTEST_PATH}/
> +   cp -r ${B}/src ${D}${PTEST_PATH}/
> +   cp -r ${S}/src/*.c ${D}${PTEST_PATH}/src
> +   cd ${D}${PTEST_PATH}
> +   tar -czvf ${D}${PTEST_PATH}/src.tar.gz ./src
> +   cd -
> +   sed -i '/^VPATH/s/= .*$/= ./g' ${D}${PTEST_PATH}/Makefile
> +   sed -i '/^PROGRAMS/s/^/#/g' ${D}${PTEST_PATH}/Makefile
> +   sed -i '/^Makefile: /s/^.*$/Makefile:/g' ${D}${PTEST_PATH}/Makefile
> +   sed -i '/^abs_srcdir/s/= .*$/= \$\{PWD\}/g' ${D}${PTEST_PATH}/Makefile
> +   sed -i '/^abs_top_builddir/s/= .*$/= \$\{PWD\}/g' 
> ${D}${PTEST_PATH}/Makefile
> +   sed -i '/^abs_top_srcdir/s/= .*$/= \$\{PWD\}/g' 
> ${D}${PTEST_PATH}/Makefile
> +   sed -i '/^built_programs/s/ginstall/install/g' 
> ${D}${PTEST_PATH}/Makefile
> +   chmod -R 777 ${D}${PTEST_PATH}
> +   # Disable subcase stty-pairs.sh, it will cause test framework hang
> +   sed -i '/stty-pairs.sh/d' ${D}${PTEST_PATH}/Makefile
> +   install ${B}/src/getlimits ${D}/${bindir}
> +}
> +
> +FILES_${PN}-ptest += "${bindir}/getlimits"
> +
> +INSANE_SKIP_${PN}-ptest += "ldflags"
> +INSANE_SKIP_${PN}-ptest += "rpaths"
> --
> 2.23.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 

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

[Ross Burton]

On 21/11/2019 08:55, Wang Mingyu wrote:

---
  .../cmake/{cmake-native_3.15.3.bb => cmake-native_3.15.5.bb}  | 0
  meta/recipes-devtools/cmake/cmake.inc | 4 ++--
  2 files changed, 2 insertions(+), 2 deletions(-)
  rename meta/recipes-devtools/cmake/{cmake-native_3.15.3.bb => 
cmake-native_3.15.5.bb} (100%)


This breaks target cmake.

Please do test your patches in a standard OE environment.

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

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

[Ross Burton]

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

Now, I am happy to accept that building it inside oe-core is somewhat
more difficult, and regenerating the autotools bits using modern tools
does look like it will require some patching, but I don't think we should
exaggerate the extent to which "old code" equals "problematic code".


Yes, the pain is entirely in the autoreconf step.  It's not a huge job, 
and it's probably easier to just delete it all and start again from 
scratch...



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


Please do!

Debian has a pile of patches too: 
https://sources.debian.org/patches/lrzsz/0.12.21-10/


All hail the new maintainer of lrzsz.  :)

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

Re: [OE-core] [PATCH v2] tune-riscv: Add support for no float

[Khem Raj]

On Thu, Nov 21, 2019 at 4:08 PM Alistair Francis
 wrote:
>
> Signed-off-by: Alistair Francis 
> ---
>  meta/conf/machine/include/riscv/arch-riscv.inc |  3 ++-
>  meta/conf/machine/include/riscv/tune-riscv.inc | 16 +++-
>  2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/meta/conf/machine/include/riscv/arch-riscv.inc 
> b/meta/conf/machine/include/riscv/arch-riscv.inc
> index f3edcc39f7..33ad6a28e1 100644
> --- a/meta/conf/machine/include/riscv/arch-riscv.inc
> +++ b/meta/conf/machine/include/riscv/arch-riscv.inc
> @@ -4,7 +4,8 @@ DEFAULTTUNE ?= "riscv64"
>
>  TUNE_ARCH = "${TUNE_ARCH_tune-${DEFAULTTUNE}}"
>  TUNE_PKGARCH = "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"
> -TUNE_CCARGS .= ""
> +TUNE_CCARGS_append_riscv64 = "${@bb.utils.contains('TUNE_FEATURES', 
> 'riscv64nf', ' -mabi=lp64', ' ', d)}"
> +TUNE_CCARGS_append_riscv32 = "${@bb.utils.contains('TUNE_FEATURES', 
> 'riscv32nf', ' -mabi=ilp32', ' ', d)}"
>

using overrides here is not required. riscv64nf and riscv32 should
conflict with each other and such a combination would
then not exist.

>  # QEMU usermode fails with invalid instruction error (For riscv32)
>  MACHINE_FEATURES_BACKFILL_CONSIDERED_append = 
> "${@bb.utils.contains('TUNE_FEATURES', 'riscv32', ' qemu-usermode', '', d)}"
> diff --git a/meta/conf/machine/include/riscv/tune-riscv.inc 
> b/meta/conf/machine/include/riscv/tune-riscv.inc
> index 25d0463492..b7dcd244d6 100644
> --- a/meta/conf/machine/include/riscv/tune-riscv.inc
> +++ b/meta/conf/machine/include/riscv/tune-riscv.inc
> @@ -3,10 +3,14 @@ require conf/machine/include/riscv/arch-riscv.inc
>  TUNEVALID[riscv64] = "Enable 64-bit RISC-V optimizations"
>  TUNEVALID[riscv32] = "Enable 32-bit RISC-V optimizations"
>
> +TUNEVALID[riscv64nf] = "Enable 64-bit RISC-V optimizations no floating point"
> +TUNEVALID[riscv32nf] = "Enable 32-bit RISC-V optimizations no floating point"
> +
>  TUNEVALID[bigendian] = "Big endian mode"
>
> -AVAILTUNES += "riscv64 riscv32"
> +AVAILTUNES += "riscv64 riscv32 riscv64nf riscv32nf"
>
> +# Default
>  TUNE_FEATURES_tune-riscv64 = "riscv64"
>  TUNE_ARCH_tune-riscv64 = "riscv64"
>  TUNE_PKGARCH_tune-riscv64 = "riscv64"
> @@ -17,3 +21,13 @@ TUNE_ARCH_tune-riscv32 = "riscv32"
>  TUNE_PKGARCH_tune-riscv32 = "riscv32"
>  PACKAGE_EXTRA_ARCHS_tune-riscv32 = "riscv32"
>
> +# No float
> +TUNE_FEATURES_tune-riscv64nf = "${TUNE_FEATURES_tune-riscv64} riscv64nf"
> +TUNE_ARCH_tune-riscv64nf = "riscv64"
> +TUNE_PKGARCH_tune-riscv64nf = "riscv64"
> +PACKAGE_EXTRA_ARCHS_tune-riscv64nf = "riscv64"
> +
> +TUNE_FEATURES_tune-riscv32nf = "${TUNE_FEATURES_tune-riscv32} riscv32nf"
> +TUNE_ARCH_tune-riscv32nf = "riscv32"
> +TUNE_PKGARCH_tune-riscv32nf = "riscv32"
> +PACKAGE_EXTRA_ARCHS_tune-riscv32nf = "riscv32"

this is not right. rv32 with float-abi wont execute on rv with soft float abi.

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

Re: [OE-core] [PATCH] gobject-introspection: Fix reproducibility

[Ross Burton]

On 21/11/2019 16:58, Joshua Watt wrote:

+Upstream-Status: Pending 
[https://gitlab.gnome.org/GNOME/gobject-introspection/merge_requests/192]


If there's a merge request, the status is Submitted.

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

Re: [OE-core] [PATCH v2] tune-riscv: Add support for no float

[Andre McCurdy]

On Thu, Nov 21, 2019 at 4:08 PM Alistair Francis
 wrote:
>
> Signed-off-by: Alistair Francis 
> ---
>  meta/conf/machine/include/riscv/arch-riscv.inc |  3 ++-
>  meta/conf/machine/include/riscv/tune-riscv.inc | 16 +++-
>  2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/meta/conf/machine/include/riscv/arch-riscv.inc 
> b/meta/conf/machine/include/riscv/arch-riscv.inc
> index f3edcc39f7..33ad6a28e1 100644
> --- a/meta/conf/machine/include/riscv/arch-riscv.inc
> +++ b/meta/conf/machine/include/riscv/arch-riscv.inc
> @@ -4,7 +4,8 @@ DEFAULTTUNE ?= "riscv64"
>
>  TUNE_ARCH = "${TUNE_ARCH_tune-${DEFAULTTUNE}}"
>  TUNE_PKGARCH = "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"
> -TUNE_CCARGS .= ""
> +TUNE_CCARGS_append_riscv64 = "${@bb.utils.contains('TUNE_FEATURES', 
> 'riscv64nf', ' -mabi=lp64', ' ', d)}"
> +TUNE_CCARGS_append_riscv32 = "${@bb.utils.contains('TUNE_FEATURES', 
> 'riscv32nf', ' -mabi=ilp32', ' ', d)}"
>
>  # QEMU usermode fails with invalid instruction error (For riscv32)
>  MACHINE_FEATURES_BACKFILL_CONSIDERED_append = 
> "${@bb.utils.contains('TUNE_FEATURES', 'riscv32', ' qemu-usermode', '', d)}"
> diff --git a/meta/conf/machine/include/riscv/tune-riscv.inc 
> b/meta/conf/machine/include/riscv/tune-riscv.inc
> index 25d0463492..b7dcd244d6 100644
> --- a/meta/conf/machine/include/riscv/tune-riscv.inc
> +++ b/meta/conf/machine/include/riscv/tune-riscv.inc
> @@ -3,10 +3,14 @@ require conf/machine/include/riscv/arch-riscv.inc
>  TUNEVALID[riscv64] = "Enable 64-bit RISC-V optimizations"
>  TUNEVALID[riscv32] = "Enable 32-bit RISC-V optimizations"
>
> +TUNEVALID[riscv64nf] = "Enable 64-bit RISC-V optimizations no floating point"
> +TUNEVALID[riscv32nf] = "Enable 32-bit RISC-V optimizations no floating point"
> +
>  TUNEVALID[bigendian] = "Big endian mode"
>
> -AVAILTUNES += "riscv64 riscv32"
> +AVAILTUNES += "riscv64 riscv32 riscv64nf riscv32nf"
>
> +# Default
>  TUNE_FEATURES_tune-riscv64 = "riscv64"
>  TUNE_ARCH_tune-riscv64 = "riscv64"
>  TUNE_PKGARCH_tune-riscv64 = "riscv64"
> @@ -17,3 +21,13 @@ TUNE_ARCH_tune-riscv32 = "riscv32"
>  TUNE_PKGARCH_tune-riscv32 = "riscv32"
>  PACKAGE_EXTRA_ARCHS_tune-riscv32 = "riscv32"
>
> +# No float
> +TUNE_FEATURES_tune-riscv64nf = "${TUNE_FEATURES_tune-riscv64} riscv64nf"
> +TUNE_ARCH_tune-riscv64nf = "riscv64"
> +TUNE_PKGARCH_tune-riscv64nf = "riscv64"
> +PACKAGE_EXTRA_ARCHS_tune-riscv64nf = "riscv64"

This seems to be saying that a riscv64nf machine can also use riscv64 packages.

Should that be the other way around (ie riscv64 machine can also use
riscv64nf packages)?

(I thought there was a sanity check somewhere to check that
PACKAGE_EXTRA_ARCHS_tune-foo must at least contain "foo", ie a
particular tune must be able to use it's own packages. I don't
remember how or when that's triggered though... maybe it's ARM
specific?).

> +TUNE_FEATURES_tune-riscv32nf = "${TUNE_FEATURES_tune-riscv32} riscv32nf"
> +TUNE_ARCH_tune-riscv32nf = "riscv32"
> +TUNE_PKGARCH_tune-riscv32nf = "riscv32"
> +PACKAGE_EXTRA_ARCHS_tune-riscv32nf = "riscv32"
> --
> 2.24.0
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] opkg: Add upstream fixes

[Khem Raj]

On Thu, Nov 21, 2019 at 7:02 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> Signed-off-by: Richard Purdie 
> ---
>  .../opkg/opkg/open_inner.patch| 150 
>  .../opkg/opkg/opkg_archive.patch  | 160 ++
>  meta/recipes-devtools/opkg/opkg_0.4.1.bb  |   2 +
>  3 files changed, 312 insertions(+)
>  create mode 100644 meta/recipes-devtools/opkg/opkg/open_inner.patch
>  create mode 100644 meta/recipes-devtools/opkg/opkg/opkg_archive.patch
>
> diff --git a/meta/recipes-devtools/opkg/opkg/open_inner.patch
> b/meta/recipes-devtools/opkg/opkg/open_inner.patch
> new file mode 100644
> index 000..9edccda33ea
> --- /dev/null
> +++ b/meta/recipes-devtools/opkg/opkg/open_inner.patch
> @@ -0,0 +1,150 @@
> +From alejandro.delcasti...@ni.com Wed Nov 20 22:35:02 2019
> +Return-Path: 
> +X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dan.rpsys.net
> +X-Spam-Level:
> +X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,
> +   HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,
> +   SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no
> version=3.4.2
> +Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com
> + [209.85.217.54]) by dan.rpsys.net (8.15.2/8.15.2/Debian-10) with ESMTPS
> id
> + xAKMZ0Lh008396 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128
> + verify=NOT) for ; Wed, 20 Nov 2019 22:35:02 GMT
> +Received: by mail-vs1-f54.google.com with SMTP id a143so842733vsd.9
> +for ; Wed, 20 Nov 2019 14:35:02 -0800 (PST)
> +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
> 1e100.net;
> + s=20161025;
> + h=x-original-authentication-results:x-gm-message-state:delivered-to
> + :from:to:cc:subject:date:message-id:in-reply-to:references
> + :mime-version:content-transfer-encoding;
> + bh=KhZ2BZSLg854tEjeyRybBtwjcbtPiM0dOPJA6ODniyc=;
> + b=gWeCNByEKyLw0dgzMAzHowAbjPywF8aHCjjjDOeFB/48Lr/e3A42S47HsxON9j+BoP
> + Ai2HT0MOqAIRWqz3tQM/1Q9mXOy0PNU2Dqpzu5u7QCZeoFX1XpXH0hbVn+JOdg3bcPwn
> + Nm+A/vS1By4S8c0EGQ+JQ6EBMc4xtpG8rOKiPuAtj5FlRVIQ1/AM8fEMrtQfFemBbIoO
> + KhGQVSmXg9CQKzPBoFR+IgiiKuUJjKBAcz7gzvQjJ6y/sCKUtk3FE8QUNeGqMGQXkD1/
> + XEWZq2qLjkEezUbqW+ixeaWUlN7EqTn0YT+g5sO9tEL4xoUR3w9KwCkdwOvUlgEftbUB
> aPCA==
> +X-Original-Authentication-Results: mx.google.com;   spf=pass
> + (google.com: domain of prvs=222760f524=alejandro.delcasti...@ni.com
> + designates 148.163.156.75 as permitted sender)
> + smtp.mailfrom="prvs=222760f524=alejandro.delcasti...@ni.com";
> + dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ni.com
> +X-Gm-Message-State:
> + APjAAAWPWaQQBF8I9vWh3dmrrR3q+FLW/OiQFoIv220MYnIHfdNqqufD
> + I54SM2ZkAI8VGILL5cnno25yyFO4MmqyzLBlkBkUHPoMGpk1l8U6Gg==
> +X-Received: by 2002:a67:f649:: with SMTP id
> + u9mr3437665vso.20.1574289295541; Wed, 20 Nov 2019 14:34:55 -0800 (PST)
> +X-Forwarded-To: rpur...@rpsys.net
> +X-Forwarded-For: richard.pur...@linuxfoundation.org rpur...@rpsys.net
> +Delivered-To: richard.pur...@linuxfoundation.org
> +Received: by 2002:a67:ca9b:0:0:0:0:0 with SMTP id a27csp2232978vsl;
> +Wed, 20 Nov 2019 14:34:53 -0800 (PST)
> +X-Google-Smtp-Source:
> +
> APXvYqzu0124T/A2v8nyGwvi00K3wFZx5WfkgZyaqKf27zfmydLbudST3y3wGviqkEtUN4fkFdsl
> +X-Received: by 2002:a17:902:d901:: with SMTP id
> + c1mr5251580plz.93.1574289293448; Wed, 20 Nov 2019 14:34:53 -0800 (PST)
> +ARC-Seal: i=1; a=rsa-sha256; t=1574289293; cv=none; d=google.com;
> + s=arc-20160816;
> + b=wICD7meblSbVcD2gv1eC5y6GdeaaEHOHrP5D7it3PNtBwqNTqRmU1F8UJWdOdmsbKu
> + JSKc9assSlXVI9F7Bu+ZsczsEbA9MqWxKmgPLS5YHVTCMU3QRwTX1uLMtdeEUmCDo2+N
> + edCAO1bdrNbsM1Yhu/7nur8mBRrmcP/2uq4cgvfV03/1i1x3YiRiLmEj/WaU1V2oGzjL
> + F8lQpfIQIcIbX0dlq28GnJKntNSDe++OMLBwlhxY5FR+lCaXhf91kw/WndILbB99U0yf
> + 6FkzOxwcTbLLahDdHDgVmtk+grUVcz0N7HnRM5Wj8FqAmbtetw/NnWovsUMUlbQRvQm5
> /xKA==
> +ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com
> ;
> + s=arc-20160816;
> + h=content-transfer-encoding:mime-version:references:in-reply-to
> + :message-id:date:subject:cc:to:from;
> + bh=KhZ2BZSLg854tEjeyRybBtwjcbtPiM0dOPJA6ODniyc=;
> + b=MIgWm3wUiLmTZuhjNXKsih84SdE0NfFoXpMJqshToFqGG8ElxCzyorlvK+0PGjN428
> + O/vMXpqOqd1iR6IZ9/wEb3JsHOrOxNWFwA1MVp/QkSKQwhjvRNl62i5C7fl7idVwuUl/
> + 7EZJZ4ZYTXEGUv+wIUuij+MAffGrqQDg0Ubd9ccVymjPA6nDLryHEbWrUepJVnKPd3nQ
> + iJxxkYgBP8QP3Aq/a3QNxqxXdMilrGeMljx0wpWwKqkBEvC913vISPJZ0nLbxglYzebM
> + K3B2Ksf4Ct7C/dXPAUjkt5mtLDYT6mZ7v8oFesgsbxvIHlKe6CCry0a5wYUqaSvfElfY
> V6kA==
> +ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com:
> + domain of prvs=222760f524=alejandro.delcasti...@ni.com designates
> + 148.163.156.75 as permitted sender)
> + smtp.mailfrom="prvs=222760f524=alejandro.delcasti...@ni.com"; dmarc=pass
> + (p=NONE sp=NONE dis=NONE) header.from=ni.com
> +Received: from mx0b-00010702.pphosted.com (mx0a-00010702.pphosted.com.
> + [148.163.156.75]) by mx.google.com with ESMTPS id
> + 4si680517plb.245.2019.11.20.14.34.53 for
> +  (version=TLS1_2
> + 

Re: [OE-core] How to backport openssl to Sumo

[Andre McCurdy]

On Thu, Nov 21, 2019 at 5:53 AM Ryan Harkin  wrote:
> On Thu, 21 Nov 2019 at 13:39, Nicolas Dechesne  
> wrote:
>> On Thu, Nov 21, 2019 at 2:15 PM Ryan Harkin  wrote:
>> > On Wed, 20 Nov 2019 at 23:53, Andre McCurdy  wrote:
>> >> On Wed, Nov 20, 2019 at 2:41 PM Ryan Harkin  
>> >> wrote:
>> >> > On Wed, 20 Nov 2019 at 21:29, Ryan Harkin  
>> >> > wrote:
>> >> >>
>> >> >> I pulled the whole openssl dir from your repo, added the layer.conf 
>> >> >> changes to my layer.conf and rebuilt openssl and my image.
>> >> >>
>> >> >> Unfortunately, I still have no /usr/bin/openssl in my disk image. So 
>> >> >> I've added the RPROVIDES from Andre's in a vain attempt to get it to 
>> >> >> work:
>> >> >>
>> >> >> RPROVIDES_${PN} += "openssl-bin"
>> >> >>
>> >> >> ... although I'm not hopeful it'll do the trick...
>> >> >
>> >> > It didn't work. Once thing that's puzzling me: where is the package 
>> >> > "openssl-bin"? I can only find references to it, but no package.
>> >>
>> >> The "openssl-bin" package is created by the openssl 1.1.x recipe.
>> >>
>> >> Adding "openssl-bin" to RPROVIDES in the openssl 1.0.2 recipe is a
>> >> solution for users who are switching from openssl 1.1.x back to 1.0.2
>> >> and have an image which is tries to include the new openssl-bin
>> >> package. I don't think that's what you are trying to do (?).
>> >
>> > Correct. I only tried it because the 1.0.2t recipe wasn't working.
>> >
>> > To be clear - I have /usr/bin/openssl in my image when using 1.0.2p from 
>> > the Poky Sumo branch. When I add the 1.0.2t recipe to my own layer, 
>> > openssl builds without errors, but I don't get the binary.
>> >
>> >> If you are using openssl 1.0.2 then the openssl command line tool is
>> >> in the openssl package... so to include the openssl command line tool,
>> >> add the "openssl" package to your image.
>> >>
>> >> If you are using openssl 1.1.x then the openssl command line tool is
>> >> in the openssl-bin package... so to include the openssl command line
>> >> tool, add the "openssl-bin" package to your image.
>> >>
>> >> But anyway, in all cases, the way to debug what's going on isn't to
>> >> try random recipe changes and then rebuild the final image. Instead
>> >> you should build your chosen version of openssl, look in the
>> >> packages-split directory to see which package includes the openssl
>> >> command line tool and then add that package to your image.
>> >
>> > I don't have a packages-split. I was unaware of it, and reading the 
>> > manual, it seems I should have one. But I don't. Running 'bitbake -e 
>> > openssl | grep "PKGDEST="' tells me I should have one, but there are no 
>> > instances in a directory called "packages-split" in my tmp dir.
>>
>> most likely because you are using rm_work.
>
> Yes, I am! Thanks, Nico.

It looks like Mark's openssl 1.0.2 recipe has added the openssl-bin
package (ie Mark's openssl 1.0.2 recipe behaves the same as the
openssl 1.1.x recipe).

My openssl 1.0.2 recipe keeps the original packaging rules (as they
were when openssl 1.0.2 was the default in oe-core).
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] tune-riscv: Add support for no float

[Alistair Francis]

Signed-off-by: Alistair Francis 
---
 meta/conf/machine/include/riscv/arch-riscv.inc |  3 ++-
 meta/conf/machine/include/riscv/tune-riscv.inc | 16 +++-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/meta/conf/machine/include/riscv/arch-riscv.inc 
b/meta/conf/machine/include/riscv/arch-riscv.inc
index f3edcc39f7..33ad6a28e1 100644
--- a/meta/conf/machine/include/riscv/arch-riscv.inc
+++ b/meta/conf/machine/include/riscv/arch-riscv.inc
@@ -4,7 +4,8 @@ DEFAULTTUNE ?= "riscv64"
 
 TUNE_ARCH = "${TUNE_ARCH_tune-${DEFAULTTUNE}}"
 TUNE_PKGARCH = "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"
-TUNE_CCARGS .= ""
+TUNE_CCARGS_append_riscv64 = "${@bb.utils.contains('TUNE_FEATURES', 
'riscv64nf', ' -mabi=lp64', ' ', d)}"
+TUNE_CCARGS_append_riscv32 = "${@bb.utils.contains('TUNE_FEATURES', 
'riscv32nf', ' -mabi=ilp32', ' ', d)}"
 
 # QEMU usermode fails with invalid instruction error (For riscv32)
 MACHINE_FEATURES_BACKFILL_CONSIDERED_append = 
"${@bb.utils.contains('TUNE_FEATURES', 'riscv32', ' qemu-usermode', '', d)}"
diff --git a/meta/conf/machine/include/riscv/tune-riscv.inc 
b/meta/conf/machine/include/riscv/tune-riscv.inc
index 25d0463492..b7dcd244d6 100644
--- a/meta/conf/machine/include/riscv/tune-riscv.inc
+++ b/meta/conf/machine/include/riscv/tune-riscv.inc
@@ -3,10 +3,14 @@ require conf/machine/include/riscv/arch-riscv.inc
 TUNEVALID[riscv64] = "Enable 64-bit RISC-V optimizations"
 TUNEVALID[riscv32] = "Enable 32-bit RISC-V optimizations"
 
+TUNEVALID[riscv64nf] = "Enable 64-bit RISC-V optimizations no floating point"
+TUNEVALID[riscv32nf] = "Enable 32-bit RISC-V optimizations no floating point"
+
 TUNEVALID[bigendian] = "Big endian mode"
 
-AVAILTUNES += "riscv64 riscv32"
+AVAILTUNES += "riscv64 riscv32 riscv64nf riscv32nf"
 
+# Default
 TUNE_FEATURES_tune-riscv64 = "riscv64"
 TUNE_ARCH_tune-riscv64 = "riscv64"
 TUNE_PKGARCH_tune-riscv64 = "riscv64"
@@ -17,3 +21,13 @@ TUNE_ARCH_tune-riscv32 = "riscv32"
 TUNE_PKGARCH_tune-riscv32 = "riscv32"
 PACKAGE_EXTRA_ARCHS_tune-riscv32 = "riscv32"
 
+# No float
+TUNE_FEATURES_tune-riscv64nf = "${TUNE_FEATURES_tune-riscv64} riscv64nf"
+TUNE_ARCH_tune-riscv64nf = "riscv64"
+TUNE_PKGARCH_tune-riscv64nf = "riscv64"
+PACKAGE_EXTRA_ARCHS_tune-riscv64nf = "riscv64"
+
+TUNE_FEATURES_tune-riscv32nf = "${TUNE_FEATURES_tune-riscv32} riscv32nf"
+TUNE_ARCH_tune-riscv32nf = "riscv32"
+TUNE_PKGARCH_tune-riscv32nf = "riscv32"
+PACKAGE_EXTRA_ARCHS_tune-riscv32nf = "riscv32"
-- 
2.24.0

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

Re: [OE-core] [PATCH] systemd-bootchart: Add RISC-V support

[Khem Raj]

On Thu, Nov 21, 2019 at 12:46 PM Richard Purdie
 wrote:
>
> On Thu, 2019-11-21 at 10:21 -0800, Khem Raj wrote:
> > This is a partial backport from upstream systemd
>
> Partial in what regard? Its incomplete and doesn't work? or we don't
> need some of it? :)

Upstream code has been re-organised before risc-v support was added to
its mix of two commits
primarily
https://github.com/systemd/systemd/commit/171b53380085b1288b03b19a2b978f36a5c003d0

https://github.com/systemd/systemd/commit/680a752c834aba1b66449d34f17dbe37e040f6b0



>
> >
> > Signed-off-by: Khem Raj 
> > ---
> >  ...itecture-Recognise-RISCV-32-RISCV-64.patch | 45
> > +++
> >  .../systemd-bootchart_233.bb  |  1 +
> >  2 files changed, 46 insertions(+)
> >  create mode 100644 meta/recipes-devtools/systemd-bootchart/systemd-
> > bootchart/0001-architecture-Recognise-RISCV-32-RISCV-64.patch
> >
> > diff --git a/meta/recipes-devtools/systemd-bootchart/systemd-
> > bootchart/0001-architecture-Recognise-RISCV-32-RISCV-64.patch
> > b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-
> > architecture-Recognise-RISCV-32-RISCV-64.patch
> > new file mode 100644
> > index 00..5e89195915
> > --- /dev/null
> > +++ b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-
> > architecture-Recognise-RISCV-32-RISCV-64.patch
> > @@ -0,0 +1,45 @@
> > +From 4a6ace0a965965ea15e88c3418c7158ca5cc9f8f Mon Sep 17 00:00:00
> > 2001
> > +From: Khem Raj 
> > +Date: Thu, 21 Nov 2019 10:12:05 -0800
> > +Subject: [PATCH] architecture: Recognise RISCV-32/RISCV-64
> > +
> > +Upstream-Status: Pending
>
> So it isn't a backport?
>
> Cheers,
>
> Richard
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 5/5] oeqa/selftest/sstatetests: Ensure we don't use hashequiv for sstatesigs tests

[Richard Purdie]

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/cases/sstatetests.py | 12 
 1 file changed, 12 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
b/meta/lib/oeqa/selftest/cases/sstatetests.py
index 2867cb78abb..6757a0ec689 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -255,6 +255,7 @@ BUILD_ARCH = "x86_64"
 BUILD_OS = "linux"
 SDKMACHINE = "x86_64"
 PACKAGE_CLASSES = "package_rpm package_ipk package_deb"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """)
 self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash")
 bitbake("core-image-sato -S none")
@@ -266,6 +267,7 @@ BUILD_ARCH = "i686"
 BUILD_OS = "linux"
 SDKMACHINE = "i686"
 PACKAGE_CLASSES = "package_rpm package_ipk package_deb"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """)
 self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash2")
 bitbake("core-image-sato -S none")
@@ -298,6 +300,7 @@ PACKAGE_CLASSES = "package_rpm package_ipk package_deb"
 TMPDIR = \"${TOPDIR}/tmp-sstatesamehash\"
 TCLIBCAPPEND = \"\"
 NATIVELSBSTRING = \"DistroA\"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """)
 self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash")
 bitbake("core-image-sato -S none")
@@ -305,6 +308,7 @@ NATIVELSBSTRING = \"DistroA\"
 TMPDIR = \"${TOPDIR}/tmp-sstatesamehash2\"
 TCLIBCAPPEND = \"\"
 NATIVELSBSTRING = \"DistroB\"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """)
 self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash2")
 bitbake("core-image-sato -S none")
@@ -332,11 +336,13 @@ NATIVELSBSTRING = \"DistroB\"
 TMPDIR = \"${TOPDIR}/tmp-sstatesamehash\"
 TCLIBCAPPEND = \"\"
 MACHINE = \"qemux86-64\"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """
 configB = """
 TMPDIR = \"${TOPDIR}/tmp-sstatesamehash2\"
 TCLIBCAPPEND = \"\"
 MACHINE = \"qemuarm\"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """
 self.sstate_allarch_samesigs(configA, configB)
 
@@ -352,6 +358,7 @@ MACHINE = \"qemux86-64\"
 require conf/multilib.conf
 MULTILIBS = \"multilib:lib32\"
 DEFAULTTUNE_virtclass-multilib-lib32 = \"x86\"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """
 configB = """
 TMPDIR = \"${TOPDIR}/tmp-sstatesamehash2\"
@@ -359,6 +366,7 @@ TCLIBCAPPEND = \"\"
 MACHINE = \"qemuarm\"
 require conf/multilib.conf
 MULTILIBS = \"\"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """
 self.sstate_allarch_samesigs(configA, configB)
 
@@ -404,6 +412,7 @@ MACHINE = \"qemux86\"
 require conf/multilib.conf
 MULTILIBS = "multilib:lib32"
 DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """)
 self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash")
 bitbake("world meta-toolchain -S none")
@@ -414,6 +423,7 @@ MACHINE = \"qemux86copy\"
 require conf/multilib.conf
 MULTILIBS = "multilib:lib32"
 DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """)
 self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash2")
 bitbake("world meta-toolchain -S none")
@@ -452,6 +462,7 @@ TIME = "11"
 DATE = "2016"
 INHERIT_remove = "buildstats-summary buildhistory uninative"
 http_proxy = ""
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """)
 self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash")
 self.track_for_cleanup(self.topdir + "/download1")
@@ -468,6 +479,7 @@ DATE = "20161212"
 INHERIT_remove = "uninative"
 INHERIT += "buildstats-summary buildhistory"
 http_proxy = "http://example.com/;
+BB_SIGNATURE_HANDLER = "OEBasicHash"
 """)
 self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash2")
 self.track_for_cleanup(self.topdir + "/download2")
-- 
2.20.1

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

[OE-core] [PATCH 4/5] core-image-full-cmdline: Add less

[Richard Purdie]

Less was coming from busybox in these images, add the full version.

[YOCTO #13630]

Signed-off-by: Richard Purdie 
---
 .../packagegroups/packagegroup-core-full-cmdline.bb  | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb 
b/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
index 2d96d1ba385..15a8e6dedc3 100644
--- a/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
+++ b/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
@@ -81,6 +81,7 @@ RDEPENDS_packagegroup-core-full-cmdline-utils = "\
 gawk \
 gmp \
 grep \
+less \
 makedevs \
 mc \
 mc-fish \
-- 
2.20.1

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

[OE-core] [PATCH 2/5] opkg-utils: Fix silent empty/broken opkg package creation

[Richard Purdie]

opkg-build was failing on hosts where tar < 1.28 and reproducibile builds
were enabled but it was doing this silently and generating corrupted
(empty) ipk files. Add a fix for this (submitted upstream).

The fix requires bash but if you're building ipk files this shoudn't be
a problem.

Signed-off-by: Richard Purdie 
---
 .../opkg-utils/opkg-utils/pipefail.patch  | 31 +++
 .../opkg-utils/opkg-utils_0.4.1.bb|  3 ++
 2 files changed, 34 insertions(+)
 create mode 100644 meta/recipes-devtools/opkg-utils/opkg-utils/pipefail.patch

diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils/pipefail.patch 
b/meta/recipes-devtools/opkg-utils/opkg-utils/pipefail.patch
new file mode 100644
index 000..55ddcc1fd20
--- /dev/null
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils/pipefail.patch
@@ -0,0 +1,31 @@
+We need opkg-build to fail if for example the tar command is passed invalid 
+options. Without this, we see silently created empty packaged where data.tar
+is zero bytes in size. This creates hard to debug problems.
+
+An example is when reproducible builds are enabled and run on old hosts like
+centos7 which has tar < 1.28:
+
+Subprocess output:tar: unrecognized option '--clamp-mtime'
+Try `tar --help' or `tar --usage' for more information.
+
+Upstream-Status: Pending
+Signed-off-by: Richard Purdie 
+
+Index: opkg-utils-0.4.1/opkg-build
+===
+--- opkg-utils-0.4.1.orig/opkg-build
 opkg-utils-0.4.1/opkg-build
+@@ -1,4 +1,4 @@
+-#!/bin/sh
++#!/bin/bash
+ 
+ : <<=cut
+ =head1 NAME
+@@ -12,6 +12,7 @@ opkg-build - construct an .opk from a di
+ #   Updated to work on Familiar Pre0.7rc1, with busybox tar.
+ #   Note it Requires: binutils-ar (since the busybox ar can't create)
+ set -e
++set -o pipefail
+ 
+ version=1.0
+ 
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb 
b/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb
index cf1e4670c65..eb6c7a3a6ad 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb
@@ -10,6 +10,7 @@ PROVIDES += "${@bb.utils.contains('PACKAGECONFIG', 
'update-alternatives', 'virtu
 SRC_URI = 
"http://git.yoctoproject.org/cgit/cgit.cgi/${BPN}/snapshot/${BPN}-${PV}.tar.gz \
file://0001-Switch-all-scripts-to-use-Python-3.x.patch \
file://0001-opkg-build-clamp-mtimes-to-SOURCE_DATE_EPOCH.patch \
+   file://pipefail.patch \
 "
 UPSTREAM_CHECK_URI = 
"http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/refs/;
 
@@ -19,6 +20,8 @@ SRC_URI[sha256sum] = 
"9ea9efdd9fe13661ad251e3a2860c1c93045adcfaa6659c3e86d9748ec
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
+RDEPENDS_${PN} += "bash"
+
 # For native builds we use the host Python
 PYTHONRDEPS = "python3 python3-shell python3-io python3-math python3-crypt 
python3-logging python3-fcntl python3-pickle python3-compression 
python3-stringold"
 PYTHONRDEPS_class-native = ""
-- 
2.20.1

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

[OE-core] [PATCH 3/5] sanity: Add check for tar older than 1.28

[Richard Purdie]

Older versions break opkg-build when reproducible builds are enabled.
Rather than trying to be selective based on which features are enabled,
lets just make this a minimum version.

Signed-off-by: Richard Purdie 
---
 meta/classes/sanity.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index a14bf53883c..12ea14796e8 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -523,6 +523,7 @@ def check_wsl(d):
 
 # Tar version 1.24 and onwards handle overwriting symlinks correctly
 # but earlier versions do not; this needs to work properly for sstate
+# Version 1.28 is needed so opkg-build works correctly when reproducibile 
builds are enabled
 def check_tar_version(sanity_data):
 from distutils.version import LooseVersion
 import subprocess
@@ -532,7 +533,9 @@ def check_tar_version(sanity_data):
 return "Unable to execute tar --version, exit code %d\n%s\n" % 
(e.returncode, e.output)
 version = result.split()[3]
 if LooseVersion(version) < LooseVersion("1.24"):
-return "Your version of tar is older than 1.24 and has bugs which will 
break builds. Please install a newer version of tar.\n"
+return "Your version of tar is older than 1.24 and has bugs which will 
break builds. Please install a newer version of tar (1.28+).\n"
+if LooseVersion(version) < LooseVersion("1.28"):
+return "Your version of tar is older than 1.28 and does not have the 
support needed to enable reproducible builds. Please install a newer version of 
tar (you could use the projects buildtoold-tarball from our last release).\n"
 return None
 
 # We use git parameters and functionality only found in 1.7.8 or later
-- 
2.20.1

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

[OE-core] [PATCH 1/5] opkg: Add upstream fixes for empty packages

[Richard Purdie]

An ipk with a zero size data.tar file caused opkg to crash with a
double free abort. Add the upstream fixes for this.

Signed-off-by: Richard Purdie 
---
 .../opkg/opkg/open_inner.patch| 46 
 .../opkg/opkg/opkg_archive.patch  | 54 +++
 meta/recipes-devtools/opkg/opkg_0.4.1.bb  |  2 +
 3 files changed, 102 insertions(+)
 create mode 100644 meta/recipes-devtools/opkg/opkg/open_inner.patch
 create mode 100644 meta/recipes-devtools/opkg/opkg/opkg_archive.patch

diff --git a/meta/recipes-devtools/opkg/opkg/open_inner.patch 
b/meta/recipes-devtools/opkg/opkg/open_inner.patch
new file mode 100644
index 000..278e099e3ac
--- /dev/null
+++ b/meta/recipes-devtools/opkg/opkg/open_inner.patch
@@ -0,0 +1,46 @@
+From alejandro.delcasti...@ni.com Wed Nov 20 22:35:02 2019
+From: Alejandro del Castillo 
+To: , 
+CC: Alejandro del Castillo 
+Subject: [opkg][PATCH 2/2] open_inner: add support for empty payloads
+Date: Wed, 20 Nov 2019 16:34:48 -0600
+Message-ID: <20191120223448.26522-3-alejandro.delcasti...@ni.com>
+X-Mailer: git-send-email 2.22.0
+In-Reply-To: <20191120223448.26522-1-alejandro.delcasti...@ni.com>
+References: <20191120223448.26522-1-alejandro.delcasti...@ni.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+Content-Transfer-Encoding: 8bit
+
+Support for empty compressed payloads need to be explicitly enabled on
+libarchive.
+
+Signed-off-by: Alejandro del Castillo 
+
+Upstream-Status: Backport
+---
+ libopkg/opkg_archive.c | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/libopkg/opkg_archive.c b/libopkg/opkg_archive.c
+index 0e9ccea..f19cece 100644
+--- a/libopkg/opkg_archive.c
 b/libopkg/opkg_archive.c
+@@ -618,6 +618,13 @@ static struct archive *open_inner(struct archive *outer)
+ goto err_cleanup;
+ }
+ 
++r = archive_read_support_format_empty(inner);
++if (r != ARCHIVE_OK) {
++opkg_msg(ERROR, "Empty format not supported: %s\n",
++ archive_error_string(inner));
++goto err_cleanup;
++}
++
+ r = archive_read_open(inner, data, NULL, inner_read, inner_close);
+ if (r != ARCHIVE_OK) {
+ opkg_msg(ERROR, "Failed to open inner archive: %s\n",
+-- 
+2.22.0
+
+
diff --git a/meta/recipes-devtools/opkg/opkg/opkg_archive.patch 
b/meta/recipes-devtools/opkg/opkg/opkg_archive.patch
new file mode 100644
index 000..3e1ebae9530
--- /dev/null
+++ b/meta/recipes-devtools/opkg/opkg/opkg_archive.patch
@@ -0,0 +1,54 @@
+From alejandro.delcasti...@ni.com Wed Nov 20 22:35:01 2019
+Return-Path: 
+From: Alejandro del Castillo 
+To: , 
+CC: Alejandro del Castillo 
+Subject: [opkg][PATCH 1/2] opkg_archive.c: avoid double free on uncompress
+ error
+Date: Wed, 20 Nov 2019 16:34:47 -0600
+Message-ID: <20191120223448.26522-2-alejandro.delcasti...@ni.com>
+X-Mailer: git-send-email 2.22.0
+In-Reply-To: <20191120223448.26522-1-alejandro.delcasti...@ni.com>
+References: <20191120223448.26522-1-alejandro.delcasti...@ni.com>
+MIME-Version: 1.0
+Content-Type: text/plain
+Content-Transfer-Encoding: 8bit
+
+The open-inner function calls archive_read_open. On error,
+archive_read_open calls inner_close, which also closes the outter
+archive. On error, return NULL directly to avoid double free.
+
+
+Upstream-Status: Backport
+
+Signed-off-by: Alejandro del Castillo 
+---
+ libopkg/opkg_archive.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libopkg/opkg_archive.c b/libopkg/opkg_archive.c
+index 3d87db1..0e9ccea 100644
+--- a/libopkg/opkg_archive.c
 b/libopkg/opkg_archive.c
+@@ -622,7 +622,7 @@ static struct archive *open_inner(struct archive *outer)
+ if (r != ARCHIVE_OK) {
+ opkg_msg(ERROR, "Failed to open inner archive: %s\n",
+  archive_error_string(inner));
+-goto err_cleanup;
++return NULL;
+ }
+ 
+ return inner;
+@@ -683,7 +683,7 @@ static struct archive *extract_outer(const char *filename, 
const char *arname)
+ 
+ inner = open_inner(outer);
+ if (!inner)
+-goto err_cleanup;
++return NULL;
+ 
+ return inner;
+ 
+-- 
+2.22.0
+
+
diff --git a/meta/recipes-devtools/opkg/opkg_0.4.1.bb 
b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
index 149ee3ca190..f0ae8b36bd1 100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.1.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
@@ -14,6 +14,8 @@ PE = "1"
 SRC_URI = 
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz \
file://opkg.conf \

file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \
+   file://opkg_archive.patch \
+   file://open_inner.patch \
file://run-ptest \
 "
 
-- 
2.20.1

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

[OE-core] OpenEmbedded Workshop at FOSDEM20 CFP

[Jon Mason]

We are proud to announce the inaugural OpenEmbedded Workshop. It is
being held on 03 February 2020 in Brussels, Belgium. The day after
FOSDEM.

The Call for Participation is open now. For more information, go to
https://pretalx.com/oe-workshop-2020/cfp

Early-bird tickets coming soon!

Thank you,
The OpenEmbedded Board
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] systemd-bootchart: Add RISC-V support

[Richard Purdie]

On Thu, 2019-11-21 at 10:21 -0800, Khem Raj wrote:
> This is a partial backport from upstream systemd

Partial in what regard? Its incomplete and doesn't work? or we don't
need some of it? :)

> 
> Signed-off-by: Khem Raj 
> ---
>  ...itecture-Recognise-RISCV-32-RISCV-64.patch | 45
> +++
>  .../systemd-bootchart_233.bb  |  1 +
>  2 files changed, 46 insertions(+)
>  create mode 100644 meta/recipes-devtools/systemd-bootchart/systemd-
> bootchart/0001-architecture-Recognise-RISCV-32-RISCV-64.patch
> 
> diff --git a/meta/recipes-devtools/systemd-bootchart/systemd-
> bootchart/0001-architecture-Recognise-RISCV-32-RISCV-64.patch
> b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-
> architecture-Recognise-RISCV-32-RISCV-64.patch
> new file mode 100644
> index 00..5e89195915
> --- /dev/null
> +++ b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-
> architecture-Recognise-RISCV-32-RISCV-64.patch
> @@ -0,0 +1,45 @@
> +From 4a6ace0a965965ea15e88c3418c7158ca5cc9f8f Mon Sep 17 00:00:00
> 2001
> +From: Khem Raj 
> +Date: Thu, 21 Nov 2019 10:12:05 -0800
> +Subject: [PATCH] architecture: Recognise RISCV-32/RISCV-64
> +
> +Upstream-Status: Pending

So it isn't a backport?

Cheers,

Richard

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

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

[Richard Purdie]

On Thu, 2019-11-21 at 14:53 -0500, Jean-Marie LEMETAYER wrote:
> On Nov 21, 2019, at 7:26 PM, Richard Purdie 
> richard.pur...@linuxfoundation.org wrote:
> > On Wed, 2019-11-20 at 10:33 +0100, Jean-Marie LEMETAYER wrote:
> > > The current NPM support have several issues:
> > >  - The current NPM fetcher downloads the dependency tree but not
> > > the other
> > >fetchers. The 'subdir' parameter was used to fix this issue.
> > >  - They are multiple issues with package names (uppercase, exotic
> > > characters,
> > >scoped packages) even if they are inside the dependencies.
> > >  - The lockdown file generation have issues. When a package
> > > depends on
> > >multiple version of the same package (all versions have the
> > > same checksum).
> > > 
> > > This patchset refactors the NPM support in Yocto:
> > >  - As the NPM algorithm for dependency management is hard to
> > > handle, the new
> > >NPM fetcher downloads only the package source (and not the
> > > dependencies,
> > >like the other fetchers) (patch submitted in the bitbake-devel 
> > > list).
> > 
> > I'm a little confused by this item.
> > 
> > If the NPM fetcher only downloads a given package's source and it
> > has
> > dependencies, where/when are the dependencies downloaded?
> > 
> > My worry here is that if the fetcher isn't downloading them, DL_DIR
> > can't contain all the needed pieces needed to reproduce a build at
> > a
> > later date?
> > 
> > I suspect I'm missing something obvious...
> 
> The magic is in the bbclass, in the do_fetch_append() function:
> https://github.com/savoirfairelinux/poky/blob/npm-refactoring-v3/meta/classes/npm.bbclass#L51
> 
> Which calls:
> https://github.com/savoirfairelinux/poky/blob/npm-refactoring-v3/bitbake/lib/bb/fetch2/npm.py#L312
> 
> Which runs the npm fetcher for each dependencies described in the
> shrinkwrap file. This is the same behavior for the do_unpack task.
> 
> 
> To be more clear, a recipe like this:
> 
> ```
> SRC_URI = "npm://registry.npmjs.org/;name=my-package;version=1.0.0"
> S = "${WORKDIR}/npm"
> ```
> 
> Will only fetch/unpack the package source without handling the
> dependencies.
> 
> But a recipe like this:
> 
> ```
> SRC_URI = "npm://registry.npmjs.org/;name=my-package;version=1.0.0"
> S = "${WORKDIR}/npm"
> 
> NPM_SHRINKWRAP = "${THISDIR}/${BPN}/npm-shrinkwrap.json"
> inherit npm
> ```
> 
> Will fetch/unpack the package and all the dependencies which are
> described in the shrinkwrap file.

That does remove some of my worries, thanks for explaining!

It does make me wonder if we shouldn't have two fetch classes and then
support a url like:
 
SRC_URI = "npm://registry.npmjs.org/;name=my-package;version=1.0.0 \
   npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json"

where the "npmsw" handler would handle the shrinkwrap file?

Basically I don't like the way the current code has to tag the
shrinkwrap file handling on to the fetcher...

> Bonus tips: you can have your base package SRC_URI using another
> fetcher than npm (e.g. git) without breaking anything. The behavior
> will still be the same.

That does start to make it clearer why this is advantageous.

Cheers,

Richard

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

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

[Jean-Marie LEMETAYER]

Hi Richard,

On Nov 21, 2019, at 7:26 PM, Richard Purdie richard.pur...@linuxfoundation.org 
wrote:
> On Wed, 2019-11-20 at 10:33 +0100, Jean-Marie LEMETAYER wrote:
>> The current NPM support have several issues:
>>  - The current NPM fetcher downloads the dependency tree but not the other
>>fetchers. The 'subdir' parameter was used to fix this issue.
>>  - They are multiple issues with package names (uppercase, exotic characters,
>>scoped packages) even if they are inside the dependencies.
>>  - The lockdown file generation have issues. When a package depends on
>>multiple version of the same package (all versions have the same 
>> checksum).
>> 
>> This patchset refactors the NPM support in Yocto:
>>  - As the NPM algorithm for dependency management is hard to handle, the new
>>NPM fetcher downloads only the package source (and not the dependencies,
>>like the other fetchers) (patch submitted in the bitbake-devel list).
> 
> I'm a little confused by this item.
> 
> If the NPM fetcher only downloads a given package's source and it has
> dependencies, where/when are the dependencies downloaded?
> 
> My worry here is that if the fetcher isn't downloading them, DL_DIR
> can't contain all the needed pieces needed to reproduce a build at a
> later date?
> 
> I suspect I'm missing something obvious...

The magic is in the bbclass, in the do_fetch_append() function:
https://github.com/savoirfairelinux/poky/blob/npm-refactoring-v3/meta/classes/npm.bbclass#L51

Which calls:
https://github.com/savoirfairelinux/poky/blob/npm-refactoring-v3/bitbake/lib/bb/fetch2/npm.py#L312

Which runs the npm fetcher for each dependencies described in the
shrinkwrap file. This is the same behavior for the do_unpack task.


To be more clear, a recipe like this:

```
SRC_URI = "npm://registry.npmjs.org/;name=my-package;version=1.0.0"
S = "${WORKDIR}/npm"
```

Will only fetch/unpack the package source without handling the
dependencies.

But a recipe like this:

```
SRC_URI = "npm://registry.npmjs.org/;name=my-package;version=1.0.0"
S = "${WORKDIR}/npm"

NPM_SHRINKWRAP = "${THISDIR}/${BPN}/npm-shrinkwrap.json"
inherit npm
```

Will fetch/unpack the package and all the dependencies which are
described in the shrinkwrap file.


Bonus tips: you can have your base package SRC_URI using another
fetcher than npm (e.g. git) without breaking anything. The behavior
will still be the same.


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

Re: [OE-core] [PATCH 3/3] sanity: Add check for tar older than 1.28

[Richard Purdie]

On Thu, 2019-11-21 at 13:14 -0600, Mark Hatle wrote:
> On 11/21/19 12:09 PM, Richard Purdie wrote:
> > On Thu, 2019-11-21 at 19:09 +0200, Adrian Bunk wrote:
> > > On Thu, Nov 21, 2019 at 04:54:12PM +, Richard Purdie wrote:
> > > > Any suggestions on how we fix it?
> > > 
> > > My preferred solution would be to replace CentOS 7 with CentOS 8
> > > as supported distribution, which would also allow to drop hacks
> > > for two major releases of gcc in various places.
> > 
> > We are working towards that, equally the older version support is
> > useful to a significant portion of our userbase so its a balancing
> > act.
> 
> RHEL 7 is still heavily used.  But if we can provide a buildtools-
> tarball that includes a new enough tar, that should be able to
> workaround the issue.

After some discussion, this is the direction we've gone. Debian 8 also
has the issue. On the autobuilder we've installed buildtools-tarball on
that and the Centos7 workers.

> > > If all other supported distribution already ship 1.28 this would
> > > solve your problem.
> > 
> > I believe that is now the case, yes.
> > 
> > > > (We could make opkg-utils-native depend on tar-native but for
> > > > most
> > > > people that isn't necessary so it seems a shame).
> > > 
> > > Building tar-native is not something that would strike me as 
> > > problematic.
> > 
> > Its an extra build dependency and extra build time, just
> > complicates
> > things. "tar-native" is in ASSUME_PROVIDED and gives bootstrap
> > issues
> > although we have the "tar-replacement-native" mechanism to account
> > for
> > this already. So possible but not entirely straightforward.

For fun I tried this. It exploded in circular dependency problems :(.

> Requiring a newer version, and suggesting to the user to use a
> buildtools-tarball (SDK) I think is a reasonable compromise.

Agreed, we reached the same conclusion. I'll tweak the patch to improve
the error message to the user.

Cheers,

Richard



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

Re: [OE-core] [PATCH 3/3] sanity: Add check for tar older than 1.28

[Mark Hatle]

On 11/21/19 12:09 PM, Richard Purdie wrote:
> On Thu, 2019-11-21 at 19:09 +0200, Adrian Bunk wrote:
>> On Thu, Nov 21, 2019 at 04:54:12PM +, Richard Purdie wrote:
>>> On Thu, 2019-11-21 at 17:50 +0200, Adrian Bunk wrote:
 On Thu, Nov 21, 2019 at 03:02:07PM +, Richard Purdie wrote:
> Older versions break opkg-build when reproducible builds are
> enabled.
> Rather than trying to be selective based on which features are
> enabled,
> lets just make this a minimum version.
> ...
> +if LooseVersion(version) < LooseVersion("1.28"):
> +return "Your version of tar is older than 1.28 and
> does
> not have the support needed to enable reproducible builds.
> Please
> install a newer version of tar.\n"
> ...

 How does "Please install a newer version of tar" work in practice
 on a supported host distribution like CentOS 7 ?

 As user I would expect such things to just work when using
 a distribution that is documented as supported.
>>>
>>> We're going to have to solve this issue on our autobuilder. Centos7
>>> already causes problems and there is documetation in the manual
>>> about
>>> it:
>>>
>>> https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#centos-packages
>>>
>>> (and the need to use EPEL)
>>>
>>> Unfortunately a newer tar isn't in EPEL.
>>
>> EPEL does not contain more recent versions of packages already
>> in RHEL/CentOS.
> 
> Sorry, I had thought Centos7 had python3 already and we needed EPEL to
> obtain python 3.6.
> 
>>
>>> I don't have a solution yet, I do know that silently creating empty
>>> packages is much worst than telling a user something won't work
>>> though.
>>>
>>> Any suggestions on how we fix it?
>>
>> My preferred solution would be to replace CentOS 7 with CentOS 8
>> as supported distribution, which would also allow to drop hacks
>> for two major releases of gcc in various places.
> 
> We are working towards that, equally the older version support is
> useful to a significant portion of our userbase so its a balancing act.

RHEL 7 is still heavily used.  But if we can provide a buildtools-tarball that
includes a new enough tar, that should be able to workaround the issue.

>> If all other supported distribution already ship 1.28 this would
>> solve your problem.
> 
> I believe that is now the case, yes.
> 
>>> (We could make opkg-utils-native depend on tar-native but for most
>>> people that isn't necessary so it seems a shame).
>>
>> Building tar-native is not something that would strike me as 
>> problematic.
> 
> Its an extra build dependency and extra build time, just complicates
> things. "tar-native" is in ASSUME_PROVIDED and gives bootstrap issues
> although we have the "tar-replacement-native" mechanism to account for
> this already. So possible but not entirely straightforward.

Requiring a newer version, and suggesting to the user to use a
buildtools-tarball (SDK) I think is a reasonable compromise.

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

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

[Richard Purdie]

On Wed, 2019-11-20 at 10:33 +0100, Jean-Marie LEMETAYER wrote:
> The current NPM support have several issues:
>  - The current NPM fetcher downloads the dependency tree but not the other
>fetchers. The 'subdir' parameter was used to fix this issue.
>  - They are multiple issues with package names (uppercase, exotic characters,
>scoped packages) even if they are inside the dependencies.
>  - The lockdown file generation have issues. When a package depends on
>multiple version of the same package (all versions have the same checksum).
> 
> This patchset refactors the NPM support in Yocto:
>  - As the NPM algorithm for dependency management is hard to handle, the new
>NPM fetcher downloads only the package source (and not the dependencies,
>like the other fetchers) (patch submitted in the bitbake-devel list).

I'm a little confused by this item.

If the NPM fetcher only downloads a given package's source and it has
dependencies, where/when are the dependencies downloaded?

My worry here is that if the fetcher isn't downloading them, DL_DIR
can't contain all the needed pieces needed to reproduce a build at a
later date?

I suspect I'm missing something obvious...

Cheers,

Richard

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

[OE-core] [PATCH] systemd-bootchart: Add RISC-V support

[Khem Raj]

This is a partial backport from upstream systemd

Signed-off-by: Khem Raj 
---
 ...itecture-Recognise-RISCV-32-RISCV-64.patch | 45 +++
 .../systemd-bootchart_233.bb  |  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 
meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-architecture-Recognise-RISCV-32-RISCV-64.patch

diff --git 
a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-architecture-Recognise-RISCV-32-RISCV-64.patch
 
b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-architecture-Recognise-RISCV-32-RISCV-64.patch
new file mode 100644
index 00..5e89195915
--- /dev/null
+++ 
b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart/0001-architecture-Recognise-RISCV-32-RISCV-64.patch
@@ -0,0 +1,45 @@
+From 4a6ace0a965965ea15e88c3418c7158ca5cc9f8f Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Thu, 21 Nov 2019 10:12:05 -0800
+Subject: [PATCH] architecture: Recognise RISCV-32/RISCV-64
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+---
+ src/architecture.h | 13 +
+ 1 file changed, 13 insertions(+)
+
+diff --git a/src/architecture.h b/src/architecture.h
+index 26679e2..89c7d32 100644
+--- a/src/architecture.h
 b/src/architecture.h
+@@ -57,6 +57,8 @@ enum {
+ ARCHITECTURE_M68K,
+ ARCHITECTURE_TILEGX,
+ ARCHITECTURE_CRIS,
++   ARCHITECTURE_RISCV32,
++   ARCHITECTURE_RISCV64,
+ _ARCHITECTURE_MAX,
+ _ARCHITECTURE_INVALID = -1
+ };
+@@ -194,6 +196,17 @@ int uname_architecture(void);
+ #elif defined(__cris__)
+ #  define native_architecture() ARCHITECTURE_CRIS
+ #  error "Missing LIB_ARCH_TUPLE for CRIS"
++#elif defined(__riscv)
++#  if __SIZEOF_POINTER__ == 4
++#define native_architecture() ARCHITECTURE_RISCV32
++#define LIB_ARCH_TUPLE "riscv32-linux-gnu"
++#  elif __SIZEOF_POINTER__ == 8
++#define native_architecture() ARCHITECTURE_RISCV64
++#define LIB_ARCH_TUPLE "riscv64-linux-gnu"
++#  else
++#error "Unrecognized riscv architecture variant"
++#  endif
++#  define PROC_CPUINFO_MODEL "cpu model"
+ #else
+ #  error "Please register your architecture here!"
+ #endif
+-- 
+2.24.0
+
diff --git a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_233.bb 
b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_233.bb
index aef8839864..960edc75e6 100644
--- a/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_233.bb
+++ b/meta/recipes-devtools/systemd-bootchart/systemd-bootchart_233.bb
@@ -3,6 +3,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c
 file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe"
 
 SRC_URI = "git://github.com/systemd/systemd-bootchart.git;protocol=https \
+   file://0001-architecture-Recognise-RISCV-32-RISCV-64.patch \
 "
 
 SRC_URI_append_libc-musl = " \
-- 
2.24.0

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

Re: [OE-core] [PATCH 3/3] sanity: Add check for tar older than 1.28

[Richard Purdie]

On Thu, 2019-11-21 at 19:09 +0200, Adrian Bunk wrote:
> On Thu, Nov 21, 2019 at 04:54:12PM +, Richard Purdie wrote:
> > On Thu, 2019-11-21 at 17:50 +0200, Adrian Bunk wrote:
> > > On Thu, Nov 21, 2019 at 03:02:07PM +, Richard Purdie wrote:
> > > > Older versions break opkg-build when reproducible builds are
> > > > enabled.
> > > > Rather than trying to be selective based on which features are
> > > > enabled,
> > > > lets just make this a minimum version.
> > > > ...
> > > > +if LooseVersion(version) < LooseVersion("1.28"):
> > > > +return "Your version of tar is older than 1.28 and
> > > > does
> > > > not have the support needed to enable reproducible builds.
> > > > Please
> > > > install a newer version of tar.\n"
> > > > ...
> > > 
> > > How does "Please install a newer version of tar" work in practice
> > > on a supported host distribution like CentOS 7 ?
> > > 
> > > As user I would expect such things to just work when using
> > > a distribution that is documented as supported.
> > 
> > We're going to have to solve this issue on our autobuilder. Centos7
> > already causes problems and there is documetation in the manual
> > about
> > it:
> > 
> > https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#centos-packages
> > 
> > (and the need to use EPEL)
> > 
> > Unfortunately a newer tar isn't in EPEL.
> 
> EPEL does not contain more recent versions of packages already
> in RHEL/CentOS.

Sorry, I had thought Centos7 had python3 already and we needed EPEL to
obtain python 3.6.

> 
> > I don't have a solution yet, I do know that silently creating empty
> > packages is much worst than telling a user something won't work
> > though.
> > 
> > Any suggestions on how we fix it?
> 
> My preferred solution would be to replace CentOS 7 with CentOS 8
> as supported distribution, which would also allow to drop hacks
> for two major releases of gcc in various places.

We are working towards that, equally the older version support is
useful to a significant portion of our userbase so its a balancing act.

> If all other supported distribution already ship 1.28 this would
> solve your problem.

I believe that is now the case, yes.

> > (We could make opkg-utils-native depend on tar-native but for most
> > people that isn't necessary so it seems a shame).
> 
> Building tar-native is not something that would strike me as 
> problematic.

Its an extra build dependency and extra build time, just complicates
things. "tar-native" is in ASSUME_PROVIDED and gives bootstrap issues
although we have the "tar-replacement-native" mechanism to account for
this already. So possible but not entirely straightforward.

Cheers,

Richard

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

Re: [OE-core] [PATCH 0/1] Adding coreutils ptest to oe-core

[Alexander Kanavin]

On Thu, 21 Nov 2019 at 18:43, Trevor Gamblin 
wrote:

> MACHINE| PASS | FAIL | SKIP | TOTAL |
> qemux86-64 |  481 |2 |  132 |   615 |
> qemuarm64  |  481 |2 |  132 |   615 |
> MACHINE| PASS | FAIL | SKIP | TOTAL |
> qemux86-64 |  483 |1 |  131 |   615 |
> qemuarm64  |  483 |1 |  131 |   615 |
>

One (and two) is very close to zero. Can you reach that?

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

[OE-core] [PATCH 0/1] Adding coreutils ptest to oe-core

[Trevor Gamblin]

From: Trevor Gamblin 

Add ptests for coreutils, but omit the most expensive tests.

core-image-minimal:

MACHINE| PASS | FAIL | SKIP | TOTAL |
qemux86-64 |  481 |2 |  132 |   615 |
qemuarm64  |  481 |2 |  132 |   615 |

core-image-sato:

MACHINE| PASS | FAIL | SKIP | TOTAL |
qemux86-64 |  483 |1 |  131 |   615 |
qemuarm64  |  483 |1 |  131 |   615 |


Trevor Gamblin (1):
  coreutils: add ptest

 .../coreutils/coreutils/run-ptest | 17 +
 meta/recipes-core/coreutils/coreutils_8.31.bb | 38 +++
 2 files changed, 55 insertions(+)
 create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest

-- 
2.23.0

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

[OE-core] [PATCH 1/1] coreutils: add ptest

[Trevor Gamblin]

From: Trevor Gamblin 

coreutils has a large number of tests, (and potential RDEPENDS
to support them), including tests added with the flags
RUN_EXPENSIVE_TESTS and RUN_VERY_EXPENSIVE_TESTS that add
significant run time for their coverage. The RUN_VERY_EXPENSIVE_TESTS
option has been omitted from the run-ptest script to reduce
some of this run time, even though this increases the SKIP count
in the results. Also, the ptest directory for coreutils is given
blanket permissions at runtime with chmod -R 777 to ensure that
the user created for the tests will be able to run the test
scripts and create the necessary files in the process.

There is still room to improve the results of this ptest without
the aforementioned additions. Of the tests marked SKIP, there
are 30 tests that are currently counted as SKIP because they
require root permissions, and another 21 that require membership
in multiple user groups. It is important to know that coreutils
has tests for both root and non-root users. Testing showed that
42 tests are skipped when running as root versus 30 when running
as a non-root user, so the decision was made to run the suite as
the latter.

Finally, note that the ptest suite for coreutils has a short
runtime on x86-64/kvm of approximately 4.5 minutes, in contrast
to the arm64 runtime of ~70 minutes.

Signed-off-by: Trevor Gamblin 
---
 .../coreutils/coreutils/run-ptest | 17 +
 meta/recipes-core/coreutils/coreutils_8.31.bb | 38 +++
 2 files changed, 55 insertions(+)
 create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest

diff --git a/meta/recipes-core/coreutils/coreutils/run-ptest 
b/meta/recipes-core/coreutils/coreutils/run-ptest
new file mode 100755
index 00..683fedee7a
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils/run-ptest
@@ -0,0 +1,17 @@
+#!/bin/bash
+
+COREUTILSLIB=/usr/lib/coreutils
+LOG="${COREUTILSLIB}/ptest/coreutils_ptest_$(date +%Y%m%d-%H%M%S).log"
+
+addgroup usergroup1
+adduser --ingroup usergroup1 tester
+
+su tester -c "make check-TESTS RUN_EXPENSIVE_TESTS=yes top_srcdir=. srcdir=." 
| tee -a ${LOG}
+deluser tester 
+delgroup usergroup1
+
+passed=`grep PASS ${LOG}|wc -l`
+failed=`grep FAIL ${LOG}|wc -l`
+skipped=`grep -E SKIP ${LOG}|wc -l`
+all=$((passed + failed + skipped))
+
diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb 
b/meta/recipes-core/coreutils/coreutils_8.31.bb
index 57b2c1bdba..5ce2730048 100644
--- a/meta/recipes-core/coreutils/coreutils_8.31.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.31.bb
@@ -143,3 +143,41 @@ python __anonymous() {
 }
 
 BBCLASSEXTEND = "native nativesdk"
+
+inherit ptest
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+ 
+SRC_URI += "file://run-ptest"
+RDEPENDS_${PN}-ptest += "bash findutils gawk gdb glibc libconvert-asn1-perl 
liberror-perl libmodule-build-perl libtimedate-perl liburi-perl make perl 
perl-module-file-stat python strace"
+
+do_install_ptest () {
+   install -d ${D}${PTEST_PATH}/tests
+   cp -r ${S}/tests/* ${D}${PTEST_PATH}/tests
+   sed -i 's/ginstall/install/g'  `grep -R ginstall 
${D}${PTEST_PATH}/tests | awk -F: '{print $1}' | uniq`
+   install -d ${D}${PTEST_PATH}/build-aux
+   install ${S}/build-aux/test-driver ${D}${PTEST_PATH}/build-aux/
+   cp ${B}/Makefile ${D}${PTEST_PATH}/
+   cp ${S}/init.cfg ${D}${PTEST_PATH}/
+   cp -r ${B}/src ${D}${PTEST_PATH}/
+   cp -r ${S}/src/*.c ${D}${PTEST_PATH}/src
+   cd ${D}${PTEST_PATH}
+   tar -czvf ${D}${PTEST_PATH}/src.tar.gz ./src
+   cd -
+   sed -i '/^VPATH/s/= .*$/= ./g' ${D}${PTEST_PATH}/Makefile
+   sed -i '/^PROGRAMS/s/^/#/g' ${D}${PTEST_PATH}/Makefile
+   sed -i '/^Makefile: /s/^.*$/Makefile:/g' ${D}${PTEST_PATH}/Makefile
+   sed -i '/^abs_srcdir/s/= .*$/= \$\{PWD\}/g' ${D}${PTEST_PATH}/Makefile
+   sed -i '/^abs_top_builddir/s/= .*$/= \$\{PWD\}/g' 
${D}${PTEST_PATH}/Makefile
+   sed -i '/^abs_top_srcdir/s/= .*$/= \$\{PWD\}/g' 
${D}${PTEST_PATH}/Makefile
+   sed -i '/^built_programs/s/ginstall/install/g' 
${D}${PTEST_PATH}/Makefile
+   chmod -R 777 ${D}${PTEST_PATH}
+   # Disable subcase stty-pairs.sh, it will cause test framework hang
+   sed -i '/stty-pairs.sh/d' ${D}${PTEST_PATH}/Makefile
+   install ${B}/src/getlimits ${D}/${bindir}
+}
+
+FILES_${PN}-ptest += "${bindir}/getlimits"
+
+INSANE_SKIP_${PN}-ptest += "ldflags"
+INSANE_SKIP_${PN}-ptest += "rpaths"
-- 
2.23.0

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

Re: [OE-core] [PATCH 3/3] sanity: Add check for tar older than 1.28

[Adrian Bunk]

On Thu, Nov 21, 2019 at 04:54:12PM +, Richard Purdie wrote:
> On Thu, 2019-11-21 at 17:50 +0200, Adrian Bunk wrote:
> > On Thu, Nov 21, 2019 at 03:02:07PM +, Richard Purdie wrote:
> > > Older versions break opkg-build when reproducible builds are
> > > enabled.
> > > Rather than trying to be selective based on which features are
> > > enabled,
> > > lets just make this a minimum version.
> > > ...
> > > +if LooseVersion(version) < LooseVersion("1.28"):
> > > +return "Your version of tar is older than 1.28 and does
> > > not have the support needed to enable reproducible builds. Please
> > > install a newer version of tar.\n"
> > > ...
> > 
> > How does "Please install a newer version of tar" work in practice
> > on a supported host distribution like CentOS 7 ?
> > 
> > As user I would expect such things to just work when using
> > a distribution that is documented as supported.
> 
> We're going to have to solve this issue on our autobuilder. Centos7
> already causes problems and there is documetation in the manual about
> it:
> 
> https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#centos-packages
> 
> (and the need to use EPEL)
> 
> Unfortunately a newer tar isn't in EPEL.

EPEL does not contain more recent versions of packages already
in RHEL/CentOS.

> I don't have a solution yet, I do know that silently creating empty
> packages is much worst than telling a user something won't work though.
> 
> Any suggestions on how we fix it?

My preferred solution would be to replace CentOS 7 with CentOS 8
as supported distribution, which would also allow to drop hacks
for two major releases of gcc in various places.

If all other supported distribution already ship 1.28 this would
solve your problem.

> (We could make opkg-utils-native depend on tar-native but for most
> people that isn't necessary so it seems a shame).

Building tar-native is not something that would strike me as 
problematic.

Add a comment why it was added, and that it can be removed again
whenever the oldest supported distribution is recent enough.

> Cheers,
> 
> Richard

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

Re: [OE-core] [PATCH 3/3] sanity: Add check for tar older than 1.28

[Alexander Kanavin]

On Thu, 21 Nov 2019 at 17:54, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

>
> Unfortunately a newer tar isn't in EPEL.
>
> I don't have a solution yet, I do know that silently creating empty
> packages is much worst than telling a user something won't work though.
>
> Any suggestions on how we fix it?
>

 Centos 8 is now out, and it does have 1.30 version of tar, so maybe we
should retire centos 7 from the autobuilder and update the list of
supported distros?

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

[OE-core] [PATCH] classes/cmake: Use relative RPATHs

[Joshua Watt]

In most cases, the RPATH is stripped out when the ELF file is packages,
but by then the damage is done from a reproducible perspective because
this absolute path is hashed as part of the build-id generated at link
time ([1] has a good explanation). Fortunately, newer cmake has an
option to generated relative RPATHs that use $ORIGIN to set the path, so
set it in the toolchain file.

[1]: https://gitlab.kitware.com/cmake/cmake/issues/18413

Signed-off-by: Joshua Watt 
---
 meta/classes/cmake.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 291f1e8d448..8ccb1eefc7d 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -120,6 +120,9 @@ set( ENV{QT_CONF_PATH} ${WORKDIR}/qt.conf )
 # directory as rpath by default
 set( CMAKE_INSTALL_RPATH ${OECMAKE_RPATH} )
 
+# Use RPATHs relative to build directory for reproducibility
+set( CMAKE_BUILD_RPATH_USE_ORIGIN ON )
+
 # Use our cmake modules
 list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/")
 
-- 
2.23.0

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

[OE-core] [PATCH] at-spi2-core: Fix reproducibility

[Joshua Watt]

Adds a patch to fix to make the -src packages reproducible

Signed-off-by: Joshua Watt 
---
 .../0001-Fix-source-reproducibility.patch | 32 +++
 .../atk/at-spi2-core_2.32.1.bb|  3 +-
 2 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-support/atk/at-spi2-core/0001-Fix-source-reproducibility.patch

diff --git 
a/meta/recipes-support/atk/at-spi2-core/0001-Fix-source-reproducibility.patch 
b/meta/recipes-support/atk/at-spi2-core/0001-Fix-source-reproducibility.patch
new file mode 100644
index 000..7631969cd62
--- /dev/null
+++ 
b/meta/recipes-support/atk/at-spi2-core/0001-Fix-source-reproducibility.patch
@@ -0,0 +1,32 @@
+From b7fa0aa00b07e03e338dd02af564431bf2f2b185 Mon Sep 17 00:00:00 2001
+From: Joshua Watt 
+Date: Wed, 20 Nov 2019 15:24:02 -0600
+Subject: [PATCH] Fix source reproducibility
+
+The generated enum type files can be included in source packages meant
+for debugging, and thus need to be reproducible. Replace the absolute
+include of the header with the basename. This is sufficient because the
+target include files are always in the include path anyway.
+
+Upstream-Status: Accepted 
[https://gitlab.gnome.org/GNOME/at-spi2-core/merge_requests/25]
+Signed-off-by: Joshua Watt 
+---
+ atspi/atspi-enum-types.c.template | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/atspi/atspi-enum-types.c.template 
b/atspi/atspi-enum-types.c.template
+index 385d0ee..92e4937 100644
+--- a/atspi/atspi-enum-types.c.template
 b/atspi/atspi-enum-types.c.template
+@@ -5,7 +5,7 @@
+ 
+ /*** BEGIN file-production ***/
+ /* enumerations from "@basename@" */
+-#include "@filename@"
++#include "@basename@"
+ 
+ /*** END file-production ***/
+ 
+-- 
+2.23.0
+
diff --git a/meta/recipes-support/atk/at-spi2-core_2.32.1.bb 
b/meta/recipes-support/atk/at-spi2-core_2.32.1.bb
index 11052a8ecef..18b5de2d581 100644
--- a/meta/recipes-support/atk/at-spi2-core_2.32.1.bb
+++ b/meta/recipes-support/atk/at-spi2-core_2.32.1.bb
@@ -5,7 +5,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=e9f288ba982d60518f375b5898283886"
 
 MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
 
-SRC_URI = "${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz"
+SRC_URI = "${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz \
+   file://0001-Fix-source-reproducibility.patch"
 
 SRC_URI[md5sum] = "998fd9d858f8fa22c4c8c15567bf6254"
 SRC_URI[sha256sum] = 
"3c2aa937ebfaca2c86569bce9b16a34fbe20d69ef0c58846313b1c42f53b0d53"
-- 
2.23.0

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

[OE-core] [PATCH] librsvg: Fix build reproducibility

[Joshua Watt]

librsvg was encoding the path to the build directory in order to find a
font file for testing. This wouldn't work in OE anyway since the build
directory isn't present at that exact location on the target, so remove
the offending path to make the build reproducible.

Signed-off-by: Joshua Watt 
---
 .../0001-Remove-non-reproducible-SRCDIR.patch | 30 +++
 meta/recipes-gnome/librsvg/librsvg_2.40.20.bb |  1 +
 2 files changed, 31 insertions(+)
 create mode 100644 
meta/recipes-gnome/librsvg/librsvg/0001-Remove-non-reproducible-SRCDIR.patch

diff --git 
a/meta/recipes-gnome/librsvg/librsvg/0001-Remove-non-reproducible-SRCDIR.patch 
b/meta/recipes-gnome/librsvg/librsvg/0001-Remove-non-reproducible-SRCDIR.patch
new file mode 100644
index 000..75fc7f9d0b9
--- /dev/null
+++ 
b/meta/recipes-gnome/librsvg/librsvg/0001-Remove-non-reproducible-SRCDIR.patch
@@ -0,0 +1,30 @@
+From bea5156cd7e7122715b26c769c35928141a1da2c Mon Sep 17 00:00:00 2001
+From: Joshua Watt 
+Date: Mon, 18 Nov 2019 14:46:34 -0600
+Subject: [PATCH] Remove non-reproducible SRCDIR
+
+Removes SRCDIR as the prefix for finding the test font. This wouldn't
+work anyway, since that path is not present on the target.
+
+This patch is specific to OE, since it appears that this entire method
+of testing was removed when upstream was re-written in rust
+
+Upstream-Status: Inappropriate [OE-specific, no longer present upstream]
+Signed-off-by: Joshua Watt 
+---
+ rsvg-cairo-draw.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/rsvg-cairo-draw.c b/rsvg-cairo-draw.c
+index caa9104..cfb7ed2 100644
+--- a/rsvg-cairo-draw.c
 b/rsvg-cairo-draw.c
+@@ -398,7 +398,7 @@ set_font_options_for_testing (PangoContext *context)
+ static void
+ create_font_config_for_testing (RsvgCairoRender *render)
+ {
+-const char *font_path = SRCDIR 
"/tests/resources/LiberationSans-Regular.ttf";
++const char *font_path = "/tests/resources/LiberationSans-Regular.ttf";
+ 
+ if (render->font_config_for_testing != NULL)
+ return;
diff --git a/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb 
b/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
index 7f98127fd01..6dd0533a5de 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.40.20.bb
@@ -20,6 +20,7 @@ inherit gnomebase gtk-doc pixbufcache 
upstream-version-is-even gobject-introspec
 
 SRC_URI += "file://gtk-option.patch \
 file://0001-Auto-detect-Bsymbolic-fixes-configure-on-macOS.patch \
+file://0001-Remove-non-reproducible-SRCDIR.patch \
 "
 
 SRC_URI[archive.md5sum] = "4949d313b0c5d9161a5c259104af5568"
-- 
2.23.0

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

[OE-core] [PATCH] gobject-introspection: Fix reproducibility

[Joshua Watt]

Adds a patch to remove build paths from gobject-introspection

Signed-off-by: Joshua Watt 
---
 .../0001-Fix-build-reproducibility.patch  | 50 +++
 .../gobject-introspection_1.62.0.bb   |  1 +
 2 files changed, 51 insertions(+)
 create mode 100644 
meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-Fix-build-reproducibility.patch

diff --git 
a/meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-Fix-build-reproducibility.patch
 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-Fix-build-reproducibility.patch
new file mode 100644
index 000..743693e9dff
--- /dev/null
+++ 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-Fix-build-reproducibility.patch
@@ -0,0 +1,50 @@
+From 59d2cbb54c012b25adeb965a94b6585d911a4539 Mon Sep 17 00:00:00 2001
+From: Joshua Watt 
+Date: Wed, 20 Nov 2019 09:03:47 -0600
+Subject: [PATCH] Fix build reproducibility
+
+ba744068 ("Make meson.override_find_program working on more complex use
+cases") made the build no longer reproducible by encoding a build system
+path into the output. This shouldn't be necessary anyway, since it
+should be possible to add new paths to search for gir files by setting
+the XDG_DATA_DIR environment variable.
+
+Closes #318
+
+Upstream-Status: Pending 
[https://gitlab.gnome.org/GNOME/gobject-introspection/merge_requests/192]
+Signed-off-by: Joshua Watt 
+---
+ girepository/girparser.c | 4 
+ meson.build  | 1 -
+ 2 files changed, 5 deletions(-)
+
+diff --git a/girepository/girparser.c b/girepository/girparser.c
+index fb47e75c..53450baf 100644
+--- a/girepository/girparser.c
 b/girepository/girparser.c
+@@ -309,10 +309,6 @@ locate_gir (GIrParser  *parser,
+   if (g_file_test (path, G_FILE_TEST_EXISTS | G_FILE_TEST_IS_REGULAR))
+ return path;
+   g_free (path);
+-  path = g_build_filename (UNINSTALLED_GIR_DIR, girname, NULL);
+-  if (g_file_test (path, G_FILE_TEST_EXISTS | G_FILE_TEST_IS_REGULAR))
+-return path;
+-  g_free (path);
+   return NULL;
+ }
+ 
+diff --git a/meson.build b/meson.build
+index d6231c5f..2f248579 100644
+--- a/meson.build
 b/meson.build
+@@ -90,7 +90,6 @@ endif
+ girdir = join_paths(gir_dir_prefix, 'gir-1.0')
+ config.set_quoted('GIR_DIR', girdir)
+ config.set_quoted('GOBJECT_INTROSPECTION_LIBDIR', 
join_paths(get_option('prefix'), get_option('libdir')))
+-config.set_quoted('UNINSTALLED_GIR_DIR', 
join_paths(meson.current_build_dir(), 'gir'))
+ 
+ foreach type : ['char', 'short', 'int', 'long']
+   size = cc.sizeof(type)
+-- 
+2.23.0
+
diff --git 
a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.62.0.bb 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.62.0.bb
index a9739cc552b..b1371776af4 100644
--- a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.62.0.bb
+++ b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.62.0.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"${GNOME_MIRROR}/${BPN}/${@oe.utils.trim_version("${PV}", 2)}/${BPN}-$

file://0001-giscanner-ignore-error-return-codes-from-ldd-wrapper.patch \
file://0001-Port-cross-compilation-support-to-meson.patch \
file://0001-meson.build-disable-tests-when-cross-compiling.patch \
+   file://0001-Fix-build-reproducibility.patch \
"
 
 SRC_URI[md5sum] = "37278eab3704e42234b6080b8cf241f1"
-- 
2.23.0

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

[OE-core] [PATCH] pango: Fix reproducibility

[Joshua Watt]

Applies a patch to fix the build reproducibility of the -src package.

Signed-off-by: Joshua Watt 
---
 .../0001-Fix-build-reproducibility.patch  | 31 +++
 meta/recipes-graphics/pango/pango_1.44.6.bb   |  3 +-
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-graphics/pango/pango/0001-Fix-build-reproducibility.patch

diff --git 
a/meta/recipes-graphics/pango/pango/0001-Fix-build-reproducibility.patch 
b/meta/recipes-graphics/pango/pango/0001-Fix-build-reproducibility.patch
new file mode 100644
index 000..03abf8763ce
--- /dev/null
+++ b/meta/recipes-graphics/pango/pango/0001-Fix-build-reproducibility.patch
@@ -0,0 +1,31 @@
+From f8b32901981a06a8db4169b82a704dcf7e8b6560 Mon Sep 17 00:00:00 2001
+From: Joshua Watt 
+Date: Wed, 20 Nov 2019 15:43:57 -0600
+Subject: [PATCH] Fix build reproducibility
+
+Changes the comment in pango-enum-types.c to reference the file basename
+instead of the full path. This ensures that the generated file is
+reproducible when it is included in source packages meant for debugging.
+
+Upstream-Status: Pending 
[https://gitlab.gnome.org/GNOME/pango/merge_requests/159]
+Signed-off-by: Joshua Watt 
+---
+ pango/pango-enum-types.c.template | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pango/pango-enum-types.c.template 
b/pango/pango-enum-types.c.template
+index d922c691..0d55ef74 100644
+--- a/pango/pango-enum-types.c.template
 b/pango/pango-enum-types.c.template
+@@ -6,7 +6,7 @@
+ /*** END file-header ***/
+ 
+ /*** BEGIN file-production ***/
+-/* enumerations from "@filename@" */
++/* enumerations from "@basename@" */
+ /*** END file-production ***/
+ 
+ /*** BEGIN value-header ***/
+-- 
+2.23.0
+
diff --git a/meta/recipes-graphics/pango/pango_1.44.6.bb 
b/meta/recipes-graphics/pango/pango_1.44.6.bb
index 8138ef72c16..c741d5836af 100644
--- a/meta/recipes-graphics/pango/pango_1.44.6.bb
+++ b/meta/recipes-graphics/pango/pango_1.44.6.bb
@@ -16,7 +16,8 @@ GNOMEBASEBUILDCLASS = "meson"
 inherit gnomebase gtk-doc ptest-gnome upstream-version-is-even 
gobject-introspection
 
 SRC_URI += "file://run-ptest \
-file://0001-Skip-thai-break-tests-without-libthai.patch"
+file://0001-Skip-thai-break-tests-without-libthai.patch \
+file://0001-Fix-build-reproducibility.patch"
 SRC_URI[archive.md5sum] = "db0a3243ba33e02aaa775412f8e5f412"
 SRC_URI[archive.sha256sum] = 
"3e1e41ba838737e200611ff001e3b304c2ca4cdbba63d200a20db0b0ddc0f86c"
 
-- 
2.23.0

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

[OE-core] [PATCH] libjitterentropy: Upgrade 2.1.2 -> 2.2.0

[Joshua Watt]

Upstream has a patch that replaces "install -s" with an INSTALL_STRIP
make variable, which can be used to replace the custom patch being
carried.

License checksum change was due to a date in the license text being
updated. The actual contents are unchanged.

Signed-off-by: Joshua Watt 
---
 ...akefile-cleanup-install-for-rebuilds.patch | 56 +++
 .../0001-fix-do_install-failure-on-oe.patch   | 33 ---
 ...opy_2.1.2.bb => libjitterentropy_2.2.0.bb} | 12 ++--
 3 files changed, 62 insertions(+), 39 deletions(-)
 create mode 100644 
meta/recipes-support/libjitterentropy/files/0001-Makefile-cleanup-install-for-rebuilds.patch
 delete mode 100644 
meta/recipes-support/libjitterentropy/files/0001-fix-do_install-failure-on-oe.patch
 rename meta/recipes-support/libjitterentropy/{libjitterentropy_2.1.2.bb => 
libjitterentropy_2.2.0.bb} (73%)

diff --git 
a/meta/recipes-support/libjitterentropy/files/0001-Makefile-cleanup-install-for-rebuilds.patch
 
b/meta/recipes-support/libjitterentropy/files/0001-Makefile-cleanup-install-for-rebuilds.patch
new file mode 100644
index 000..a19b2522935
--- /dev/null
+++ 
b/meta/recipes-support/libjitterentropy/files/0001-Makefile-cleanup-install-for-rebuilds.patch
@@ -0,0 +1,56 @@
+From 060b9b4147f6e5ff386a8b017796118d783e59fa Mon Sep 17 00:00:00 2001
+From: Matt Weber 
+Date: Tue, 22 Oct 2019 12:44:30 -0500
+Subject: [PATCH] Makefile: cleanup install for rebuilds
+
+Support the ability to rebuild and redeploy without a clean. This
+required some force linking and man archive creation.
+
+Provide the ability to override the stripping of the shared lib for
+cases where a embedded target build may want to control stripping
+or provide cross arch tools.
+
+Upstream-Status: Accepted [060b9b4147f6e5ff386a8b017796118d783e59fa]
+Signed-off-by: Matthew Weber 
+Signed-off-by: Stephan Mueller 
+Signed-off-by: Joshua Watt 
+---
+ Makefile | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 4ff069b..2e78607 100644
+--- a/Makefile
 b/Makefile
+@@ -14,6 +14,8 @@ LIBDIR := lib
+ # include target directory
+ INCDIR := include
+ 
++INSTALL_STRIP ?= install -s
++
+ NAME := jitterentropy
+ LIBMAJOR=$(shell cat jitterentropy-base.c | grep define | grep MAJVERSION | 
awk '{print $$3}')
+ LIBMINOR=$(shell cat jitterentropy-base.c | grep define | grep MINVERSION | 
awk '{print $$3}')
+@@ -58,15 +60,15 @@ cppcheck:
+ install:
+   install -d -m 0755 $(DESTDIR)$(PREFIX)/share/man/man3
+   install -m 644 doc/$(NAME).3 $(DESTDIR)$(PREFIX)/share/man/man3/
+-  gzip -9 $(DESTDIR)$(PREFIX)/share/man/man3/$(NAME).3
++  gzip -f -9 $(DESTDIR)$(PREFIX)/share/man/man3/$(NAME).3
+   install -d -m 0755 $(DESTDIR)$(PREFIX)/$(LIBDIR)
+-  install -m 0755 -s lib$(NAME).so.$(LIBVERSION) 
$(DESTDIR)$(PREFIX)/$(LIBDIR)/
++  $(INSTALL_STRIP) -m 0755 lib$(NAME).so.$(LIBVERSION) 
$(DESTDIR)$(PREFIX)/$(LIBDIR)/
+   install -d -m 0755 $(DESTDIR)$(PREFIX)/$(INCDIR)
+   install -m 0644 jitterentropy.h $(DESTDIR)$(PREFIX)/$(INCDIR)/
+   install -m 0644 jitterentropy-base-user.h $(DESTDIR)$(PREFIX)/$(INCDIR)/
+   $(RM) $(DESTDIR)$(PREFIX)/$(LIBDIR)/lib$(NAME).so.$(LIBMAJOR)
+-  ln -s lib$(NAME).so.$(LIBVERSION) 
$(DESTDIR)$(PREFIX)/$(LIBDIR)/lib$(NAME).so.$(LIBMAJOR)
+-  ln -s lib$(NAME).so.$(LIBMAJOR) 
$(DESTDIR)$(PREFIX)/$(LIBDIR)/lib$(NAME).so
++  ln -sf lib$(NAME).so.$(LIBVERSION) 
$(DESTDIR)$(PREFIX)/$(LIBDIR)/lib$(NAME).so.$(LIBMAJOR)
++  ln -sf lib$(NAME).so.$(LIBMAJOR) 
$(DESTDIR)$(PREFIX)/$(LIBDIR)/lib$(NAME).so
+ 
+ clean:
+   @- $(RM) $(NAME)
+-- 
+2.23.0
+
diff --git 
a/meta/recipes-support/libjitterentropy/files/0001-fix-do_install-failure-on-oe.patch
 
b/meta/recipes-support/libjitterentropy/files/0001-fix-do_install-failure-on-oe.patch
deleted file mode 100644
index 30ff4feb6b7..000
--- 
a/meta/recipes-support/libjitterentropy/files/0001-fix-do_install-failure-on-oe.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From 00cefca0eefecec657969b50cd4e1ed5b057a857 Mon Sep 17 00:00:00 2001
-From: Hongxu Jia 
-Date: Thu, 25 Oct 2018 16:30:06 +0800
-Subject: [PATCH] fix do_install failure on oe
-
-- Do not strip at do_install
-
-- Create includedir
-
-Upstream-Status: Pending
-
-Signed-off-by: Hongxu Jia 

- Makefile | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/Makefile b/Makefile
-index 5e31276..76fcbfa 100644
 a/Makefile
-+++ b/Makefile
-@@ -51,7 +51,8 @@ install:
-   install -m 644 doc/$(NAME).3 $(DESTDIR)$(PREFIX)/share/man/man3/
-   gzip -9 $(DESTDIR)$(PREFIX)/share/man/man3/$(NAME).3
-   install -d -m 0755 $(DESTDIR)$(PREFIX)/$(LIBDIR)
--  install -m 0755 -s lib$(NAME).so.$(LIBVERSION) 
$(DESTDIR)$(PREFIX)/$(LIBDIR)/
-+  install -m 0755 lib$(NAME).so.$(LIBVERSION) 
$(DESTDIR)$(PREFIX)/$(LIBDIR)/
-+  install -d -m 0755 $(DESTDIR)$(PREFIX)/$(INCDIR)/
-   install -m 0644 jitterentropy.h 

Re: [OE-core] [PATCH 3/3] sanity: Add check for tar older than 1.28

[Richard Purdie]

On Thu, 2019-11-21 at 17:50 +0200, Adrian Bunk wrote:
> On Thu, Nov 21, 2019 at 03:02:07PM +, Richard Purdie wrote:
> > Older versions break opkg-build when reproducible builds are
> > enabled.
> > Rather than trying to be selective based on which features are
> > enabled,
> > lets just make this a minimum version.
> > ...
> > +if LooseVersion(version) < LooseVersion("1.28"):
> > +return "Your version of tar is older than 1.28 and does
> > not have the support needed to enable reproducible builds. Please
> > install a newer version of tar.\n"
> > ...
> 
> How does "Please install a newer version of tar" work in practice
> on a supported host distribution like CentOS 7 ?
> 
> As user I would expect such things to just work when using
> a distribution that is documented as supported.

We're going to have to solve this issue on our autobuilder. Centos7
already causes problems and there is documetation in the manual about
it:

https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#centos-packages

(and the need to use EPEL)

Unfortunately a newer tar isn't in EPEL.

I don't have a solution yet, I do know that silently creating empty
packages is much worst than telling a user something won't work though.

Any suggestions on how we fix it?

(We could make opkg-utils-native depend on tar-native but for most
people that isn't necessary so it seems a shame).

Cheers,

Richard

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

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

[Richard Purdie]

On Thu, 2019-11-21 at 17:36 +0200, Adrian Bunk wrote:
> There are also two higher level topics that should be discussed:
> 
> 1. Removal of maintainers.inc
> There is some nitpicking that every recipe needs a maintainer.
> For the package in question the maintainer is not involved in the 
> discussion, and doesn't seem to have been asked for support or
> asked regarding the suggested removal.

There are pros and cons to having it. Having people who help look after
specific recipes is appreciated. Some maintainers are more active than
others and people's free time varies. We found one of the corner cases
here, the fact there are some surprises no one.

If we remove it does the situation improve? I'd say not.

FWIW the number of recipes up to date has improved recently (or feels
to have) and the process does encourage people to send updates.

Reality is there are shades of grey. By that I mean that we are never
going to have a 100% definitive/defined process which works all of the
time in every case.

We're doing the best we can and I'm not sure this discussion is going
to be productive as I don't see a path where this discussion improves
things.

> 2. Who is responsible for fixing gettext breakages in meta-oe?
> Alexander or Khem?

or the wider community? They can certainly help.

Cheers,

Richard

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

Re: [OE-core] [PATCH 3/3] sanity: Add check for tar older than 1.28

[Adrian Bunk]

On Thu, Nov 21, 2019 at 03:02:07PM +, Richard Purdie wrote:
> Older versions break opkg-build when reproducible builds are enabled.
> Rather than trying to be selective based on which features are enabled,
> lets just make this a minimum version.
>...
> +if LooseVersion(version) < LooseVersion("1.28"):
> +return "Your version of tar is older than 1.28 and does not have the 
> support needed to enable reproducible builds. Please install a newer version 
> of tar.\n"
>...

How does "Please install a newer version of tar" work in practice
on a supported host distribution like CentOS 7 ?

As user I would expect such things to just work when using
a distribution that is documented as supported.

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

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

[Adrian Bunk]

On Thu, Nov 21, 2019 at 09:24:34AM +, Ross Burton wrote:
>...
> So, if zmodem is still a useful feature to have in core, then is anyone
> willing to step up and either:
> 1) maintain the recipe.  I'd love someone who uses lrzsz to put a fork up on
> github, integrate all of our patches, and start maintaining it. Maybe then
> other distributions who still ship it will join in too.
>...

In embedded development there are some usecases left for this codebase 
from the 1980s that implements protocols that were widely popular in
the 1980s and early 1990s.

Ancient code implementing obsolete ancient stuff is not fun to maintain.


There are also two higher level topics that should be discussed:

1. Removal of maintainers.inc
There is some nitpicking that every recipe needs a maintainer.
For the package in question the maintainer is not involved in the 
discussion, and doesn't seem to have been asked for support or
asked regarding the suggested removal.

2. Who is responsible for fixing gettext breakages in meta-oe?
Alexander or Khem?


> Ross

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

[OE-core] [meta-oe][PATCH] multimedia: janus-gateway: Added new recipe

[Marek Belisko]

Signed-off-by: Marek Belisko 
Signed-off-by: Jake Withecombe 
---
 .../janus-gateway/files/janus-gateway.service  | 14 +++
 .../janus-gateway/janus-gateway_0.7.4.bb   | 48 ++
 2 files changed, 62 insertions(+)
 create mode 100644 
meta-multimedia/recipes-multimedia/janus-gateway/files/janus-gateway.service
 create mode 100644 
meta-multimedia/recipes-multimedia/janus-gateway/janus-gateway_0.7.4.bb

diff --git 
a/meta-multimedia/recipes-multimedia/janus-gateway/files/janus-gateway.service 
b/meta-multimedia/recipes-multimedia/janus-gateway/files/janus-gateway.service
new file mode 100644
index 000..5b4d4f2
--- /dev/null
+++ 
b/meta-multimedia/recipes-multimedia/janus-gateway/files/janus-gateway.service
@@ -0,0 +1,14 @@
+[Unit]
+Description=Janus WebRTC Server
+After=network.target network-online.target
+Wants=network-online.target
+
+[Service]
+Type=simple
+ExecStart=/usr/bin/janus -o
+Restart=always
+RestartSec=60
+LimitNOFILE=65536
+
+[Install]
+WantedBy=multi-user.target
diff --git 
a/meta-multimedia/recipes-multimedia/janus-gateway/janus-gateway_0.7.4.bb 
b/meta-multimedia/recipes-multimedia/janus-gateway/janus-gateway_0.7.4.bb
new file mode 100644
index 000..bca716f
--- /dev/null
+++ b/meta-multimedia/recipes-multimedia/janus-gateway/janus-gateway_0.7.4.bb
@@ -0,0 +1,48 @@
+DESCRIPTION = "Janus is an open source, general purpose, WebRTC server 
designed and developed by Meetecho"
+HOMEPAGE = "https://janus.conf.meetecho.com/;
+SECTION = "libs/multimedia"
+
+LICENSE = "GPLv3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=c9e0a79f2244c2f79cda22ea5fed9135"
+
+SRC_URI = "https://github.com/meetecho/janus-gateway/archive/v${PV}.tar.gz \
+  file://janus-gateway.service \
+"
+
+SRC_URI[md5sum] = "b068ac2b40ae800d83f471b8189bc87c"
+SRC_URI[sha256sum] = 
"01ddaf204203a1219dd46a5ce70b548bab75bc494c9ba05429f8fb1e786b2995"
+
+inherit autotools-brokensep pkgconfig systemd
+
+DEPENDS = "libsrtp jansson libconfig libnice openssl glib-2.0 gengetopt-native"
+
+PACKAGECONFIG ?= "rest_api rest"
+#PACKAGECONFIG[disablewarnings] = "--disable-warnings-as-errors,,"
+#PACKAGECONFIG[inet] = "--enable-inet,--disable-inet,"
+#PACKAGECONFIG[inet6] = "--enable-inet6,--disable-inet6,"
+PACKAGECONFIG[rest_api] = "--enable-turn-rest-api,--disable-turn-rest-api,curl"
+PACKAGECONFIG[rest] = "--enable-rest,--disable-rest,libmicrohttpd"
+PACKAGECONFIG[unix_sockets] = "--enable-unix-sockets,--disable-unix-sockets,"
+PACKAGECONFIG[post_processing] = 
"--enable-post-processing,--disable-post-processing,"
+PACKAGECONFIG[plugin_echo] = 
"--enable-plugin-echotest,--disable-plugin-echotest,"
+PACKAGECONFIG[plugin_videocall] = 
"--enable-plugin-videocall,--disable-plugin-videocall,"
+PACKAGECONFIG[plugin_nosip] = "--enable-plugin-nosip,--disable-plugin-nosip,"
+PACKAGECONFIG[plugin_videoroom] = 
"--enable-plugin-videoroom,--disable-plugin-videoroom,"
+PACKAGECONFIG[plugin_voicemail] = 
"--enable-plugin-voicemail,--disable-plugin-voicemail,"
+PACKAGECONFIG[plugin_recordplay] = 
"--enable-plugin-recordplay,--disable-plugin-recordplay,"
+PACKAGECONFIG[plugin_textroom] = 
"--enable-plugin-textroom,--disable-plugin-textroom,"
+
+FILES_${PN}_append = " ${libdir}/janus/plugins/* ${libdir}/janus/transports/* 
${libdir}/janus/events"
+FILES_${PN}-demo = "${datadir}/janus/*"
+
+PACKAGES_append = " ${PN}-demo"
+
+INSANE_SKIP_${PN} = "dev-so"
+
+SYSTEMD_SERVICE_${PN} = "janus-gateway.service"
+
+do_install_append() {
+   # Install the systemd service so we can kick start on boot
+   install -d ${D}${systemd_unitdir}/system
+   install -m 644 ${WORKDIR}/janus-gateway.service 
${D}${systemd_unitdir}/system/
+}
-- 
2.7.4

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

[OE-core] [PATCH] ghostscript: CVE-2019-14869

[Stefan Ghinea]

A flaw was found in all versions of ghostscript 9.x before 9.28,
where the `.charkeys` procedure, where it did not properly secure
its privileged calls, enabling scripts to bypass `-dSAFER` restrictions.
An attacker could abuse this flaw by creating a specially crafted
PostScript file that could escalate privileges within the Ghostscript
and access files outside of restricted areas or execute commands.

References:
https://nvd.nist.gov/vuln/detail/CVE-2019-14869

Upstream patches:
https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=485904

Signed-off-by: Stefan Ghinea 
---
 .../ghostscript/CVE-2019-14869-0001.patch | 70 +++
 .../ghostscript/ghostscript_9.27.bb   |  2 +
 2 files changed, 72 insertions(+)
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-14869-0001.patch

diff --git 
a/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-14869-0001.patch 
b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-14869-0001.patch
new file mode 100644
index 00..715ec1c450
--- /dev/null
+++ b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-14869-0001.patch
@@ -0,0 +1,70 @@
+From 485904772c5f0aa1140032746e5a0abfc40f4cef Mon Sep 17 00:00:00 2001
+From: Chris Liddell 
+Date: Tue, 5 Nov 2019 09:45:27 +
+Subject: [PATCH] Bug 701841: remove .forceput from /.charkeys
+
+When loading Type 1 or Truetype fonts from disk, we attempt to extend the glyph
+name table to include all identifiable glyph names from the Adobe Glyph List.
+
+In the case of Type 1 fonts, the font itself (almost always) marks the
+CharStrings dictionary as read-only, hence we have to use .forceput for that
+case.
+
+But for Truetype fonts, the CharStrings dictionary is created internally and is
+not read-only until *after* we have fully populated it (including the extended
+glyph names from the AGL), hence there is no need for .forceput, and no need to
+carry the security risk of using it.
+
+Replace with regular put.
+
+CVE: CVE-2019-14869
+Upstream-Status: Backport [git://git.ghostscript.com/ghostpdl.git]
+
+Signed-off-by: Stefan Ghinea 
+---
+ Resource/Init/gs_ttf.ps | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/Resource/Init/gs_ttf.ps b/Resource/Init/gs_ttf.ps
+index e34967d..5354ff0 100644
+--- a/Resource/Init/gs_ttf.ps
 b/Resource/Init/gs_ttf.ps
+@@ -1301,7 +1301,7 @@ currentdict /.pickcmap_with_no_xlatmap .undef
+   TTFDEBUG { (\n1 setting alias: ) print dup ==only
+ ( to be the same as  ) print 2 index //== exec } if
+ 
+-  7 index 2 index 3 -1 roll exch .forceput
++  7 index 2 index 3 -1 roll exch put
+ } forall
+ pop pop pop
+   }
+@@ -1319,7 +1319,7 @@ currentdict /.pickcmap_with_no_xlatmap .undef
+   exch pop
+   TTFDEBUG { (\n2 setting alias: ) print 1 index ==only
+  ( to use glyph index: ) print dup //== exec } if
+-  5 index 3 1 roll .forceput
++  5 index 3 1 roll put
+   //false
+ }
+ {
+@@ -1336,7 +1336,7 @@ currentdict /.pickcmap_with_no_xlatmap .undef
+ {%  CharStrings(dict) isunicode(boolean) 
cmap(dict) RAGL(dict) gname(name) codep(integer) gindex(integer)
+   TTFDEBUG { (\3 nsetting alias: ) print 1 index ==only
+ ( to be index: ) print dup //== exec } if
+-  exch pop 5 index 3 1 roll .forceput
++  exch pop 5 index 3 1 roll put
+ }
+ {
+   pop pop
+@@ -1366,7 +1366,7 @@ currentdict /.pickcmap_with_no_xlatmap .undef
+   } ifelse
+ ]
+   TTFDEBUG { (Encoding: ) print dup === flush } if
+-} .bind executeonly odef  % hides .forceput
++} .bind odef
+ 
+ %  CIDFontType 2 font loading  %
+ 
+-- 
+2.20.1
+
diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.27.bb 
b/meta/recipes-extended/ghostscript/ghostscript_9.27.bb
index 9e1f3e2f49..a7eab5e603 100644
--- a/meta/recipes-extended/ghostscript/ghostscript_9.27.bb
+++ b/meta/recipes-extended/ghostscript/ghostscript_9.27.bb
@@ -28,6 +28,8 @@ SRC_URI_BASE = 
"https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/d
 file://CVE-2019-14811-0001.patch \
 file://CVE-2019-14817-0001.patch \
 file://CVE-2019-14817-0002.patch \
+file://CVE-2019-14869-0001.patch \
+
 "
 
 SRC_URI = "${SRC_URI_BASE} \
-- 
2.20.1

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

[OE-core] Disbanding SWAT team/process

[Richard Purdie]

It is with reluctance, after discussion with the TSC, that we've
decided to disband the build failure SWAT process.

The reason is simple, there were no longer enough people willing to
participate in the process to make it viable.

This process was there to try and offload some of the build failure
handling (from me in particular) and try and engage a wider group of
developers with the patch review/testing process. This worked with a
rotating team of people ensuring failures were entered into the
bugzilla with the appropriate information. It worked on the assumption
that with a large team (12+), occasionally doing it wasn't a burden.
The assumption no longer holds with 5 people left.

The process did have issues with consistency and there are valid
concerns about whether the people helping with the process had enough
context to be effective too.

>From now on, people triggering builds are responsible for their own
failures. Automated builds will fall to me (Richard).

I'm taking that work on since it underpins the project quality and its
of key importance that the build failures do get handled.

I'd like to thank everyone who worked on the team over the years, it
has been a big help and was much appreciated.

Regards,

Richard


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

[OE-core] [PATCH 3/3] sanity: Add check for tar older than 1.28

[Richard Purdie]

Older versions break opkg-build when reproducible builds are enabled.
Rather than trying to be selective based on which features are enabled,
lets just make this a minimum version.

Signed-off-by: Richard Purdie 
---
 meta/classes/sanity.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index a14bf53883c..0179fb8c687 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -523,6 +523,7 @@ def check_wsl(d):
 
 # Tar version 1.24 and onwards handle overwriting symlinks correctly
 # but earlier versions do not; this needs to work properly for sstate
+# Version 1.28 is needed so opkg-build works correctly when reproducibile 
builds are enabled
 def check_tar_version(sanity_data):
 from distutils.version import LooseVersion
 import subprocess
@@ -532,7 +533,9 @@ def check_tar_version(sanity_data):
 return "Unable to execute tar --version, exit code %d\n%s\n" % 
(e.returncode, e.output)
 version = result.split()[3]
 if LooseVersion(version) < LooseVersion("1.24"):
-return "Your version of tar is older than 1.24 and has bugs which will 
break builds. Please install a newer version of tar.\n"
+return "Your version of tar is older than 1.24 and has bugs which will 
break builds. Please install a newer version of tar (1.28+).\n"
+if LooseVersion(version) < LooseVersion("1.28"):
+return "Your version of tar is older than 1.28 and does not have the 
support needed to enable reproducible builds. Please install a newer version of 
tar.\n"
 return None
 
 # We use git parameters and functionality only found in 1.7.8 or later
-- 
2.20.1

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

[OE-core] [PATCH 1/3] opkg: Add upstream fixes

[Richard Purdie]

Signed-off-by: Richard Purdie 
---
 .../opkg/opkg/open_inner.patch| 150 
 .../opkg/opkg/opkg_archive.patch  | 160 ++
 meta/recipes-devtools/opkg/opkg_0.4.1.bb  |   2 +
 3 files changed, 312 insertions(+)
 create mode 100644 meta/recipes-devtools/opkg/opkg/open_inner.patch
 create mode 100644 meta/recipes-devtools/opkg/opkg/opkg_archive.patch

diff --git a/meta/recipes-devtools/opkg/opkg/open_inner.patch 
b/meta/recipes-devtools/opkg/opkg/open_inner.patch
new file mode 100644
index 000..9edccda33ea
--- /dev/null
+++ b/meta/recipes-devtools/opkg/opkg/open_inner.patch
@@ -0,0 +1,150 @@
+From alejandro.delcasti...@ni.com Wed Nov 20 22:35:02 2019
+Return-Path: 
+X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dan.rpsys.net
+X-Spam-Level: 
+X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,
+   HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,
+   SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2
+Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com
+ [209.85.217.54]) by dan.rpsys.net (8.15.2/8.15.2/Debian-10) with ESMTPS id
+ xAKMZ0Lh008396 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128
+ verify=NOT) for ; Wed, 20 Nov 2019 22:35:02 GMT
+Received: by mail-vs1-f54.google.com with SMTP id a143so842733vsd.9
+for ; Wed, 20 Nov 2019 14:35:02 -0800 (PST)
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;
+ s=20161025;
+ h=x-original-authentication-results:x-gm-message-state:delivered-to
+ :from:to:cc:subject:date:message-id:in-reply-to:references
+ :mime-version:content-transfer-encoding;
+ bh=KhZ2BZSLg854tEjeyRybBtwjcbtPiM0dOPJA6ODniyc=;
+ b=gWeCNByEKyLw0dgzMAzHowAbjPywF8aHCjjjDOeFB/48Lr/e3A42S47HsxON9j+BoP
+ Ai2HT0MOqAIRWqz3tQM/1Q9mXOy0PNU2Dqpzu5u7QCZeoFX1XpXH0hbVn+JOdg3bcPwn
+ Nm+A/vS1By4S8c0EGQ+JQ6EBMc4xtpG8rOKiPuAtj5FlRVIQ1/AM8fEMrtQfFemBbIoO
+ KhGQVSmXg9CQKzPBoFR+IgiiKuUJjKBAcz7gzvQjJ6y/sCKUtk3FE8QUNeGqMGQXkD1/
+ XEWZq2qLjkEezUbqW+ixeaWUlN7EqTn0YT+g5sO9tEL4xoUR3w9KwCkdwOvUlgEftbUB aPCA==
+X-Original-Authentication-Results: mx.google.com;   spf=pass
+ (google.com: domain of prvs=222760f524=alejandro.delcasti...@ni.com
+ designates 148.163.156.75 as permitted sender)
+ smtp.mailfrom="prvs=222760f524=alejandro.delcasti...@ni.com";  
+ dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ni.com
+X-Gm-Message-State:
+ APjAAAWPWaQQBF8I9vWh3dmrrR3q+FLW/OiQFoIv220MYnIHfdNqqufD
+ I54SM2ZkAI8VGILL5cnno25yyFO4MmqyzLBlkBkUHPoMGpk1l8U6Gg==
+X-Received: by 2002:a67:f649:: with SMTP id
+ u9mr3437665vso.20.1574289295541; Wed, 20 Nov 2019 14:34:55 -0800 (PST)
+X-Forwarded-To: rpur...@rpsys.net
+X-Forwarded-For: richard.pur...@linuxfoundation.org rpur...@rpsys.net
+Delivered-To: richard.pur...@linuxfoundation.org
+Received: by 2002:a67:ca9b:0:0:0:0:0 with SMTP id a27csp2232978vsl;
+Wed, 20 Nov 2019 14:34:53 -0800 (PST)
+X-Google-Smtp-Source:
+ APXvYqzu0124T/A2v8nyGwvi00K3wFZx5WfkgZyaqKf27zfmydLbudST3y3wGviqkEtUN4fkFdsl
+X-Received: by 2002:a17:902:d901:: with SMTP id
+ c1mr5251580plz.93.1574289293448; Wed, 20 Nov 2019 14:34:53 -0800 (PST)
+ARC-Seal: i=1; a=rsa-sha256; t=1574289293; cv=none; d=google.com;
+ s=arc-20160816;
+ b=wICD7meblSbVcD2gv1eC5y6GdeaaEHOHrP5D7it3PNtBwqNTqRmU1F8UJWdOdmsbKu
+ JSKc9assSlXVI9F7Bu+ZsczsEbA9MqWxKmgPLS5YHVTCMU3QRwTX1uLMtdeEUmCDo2+N
+ edCAO1bdrNbsM1Yhu/7nur8mBRrmcP/2uq4cgvfV03/1i1x3YiRiLmEj/WaU1V2oGzjL
+ F8lQpfIQIcIbX0dlq28GnJKntNSDe++OMLBwlhxY5FR+lCaXhf91kw/WndILbB99U0yf
+ 6FkzOxwcTbLLahDdHDgVmtk+grUVcz0N7HnRM5Wj8FqAmbtetw/NnWovsUMUlbQRvQm5 /xKA==
+ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
+ s=arc-20160816;
+ h=content-transfer-encoding:mime-version:references:in-reply-to
+ :message-id:date:subject:cc:to:from;
+ bh=KhZ2BZSLg854tEjeyRybBtwjcbtPiM0dOPJA6ODniyc=;
+ b=MIgWm3wUiLmTZuhjNXKsih84SdE0NfFoXpMJqshToFqGG8ElxCzyorlvK+0PGjN428
+ O/vMXpqOqd1iR6IZ9/wEb3JsHOrOxNWFwA1MVp/QkSKQwhjvRNl62i5C7fl7idVwuUl/
+ 7EZJZ4ZYTXEGUv+wIUuij+MAffGrqQDg0Ubd9ccVymjPA6nDLryHEbWrUepJVnKPd3nQ
+ iJxxkYgBP8QP3Aq/a3QNxqxXdMilrGeMljx0wpWwKqkBEvC913vISPJZ0nLbxglYzebM
+ K3B2Ksf4Ct7C/dXPAUjkt5mtLDYT6mZ7v8oFesgsbxvIHlKe6CCry0a5wYUqaSvfElfY V6kA==
+ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com:
+ domain of prvs=222760f524=alejandro.delcasti...@ni.com designates
+ 148.163.156.75 as permitted sender)
+ smtp.mailfrom="prvs=222760f524=alejandro.delcasti...@ni.com"; dmarc=pass
+ (p=NONE sp=NONE dis=NONE) header.from=ni.com
+Received: from mx0b-00010702.pphosted.com (mx0a-00010702.pphosted.com.
+ [148.163.156.75]) by mx.google.com with ESMTPS id
+ 4si680517plb.245.2019.11.20.14.34.53 for
+  (version=TLS1_2
+ cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 14:34:53
+ -0800 (PST)
+Received-SPF: pass (google.com: domain of
+ prvs=222760f524=alejandro.delcasti...@ni.com designates 148.163.156.75 as
+ permitted sender) client-ip=148.163.156.75;
+Authentication-Results: 

[OE-core] [PATCH 2/3] opkg-utils: Fix silent empty/broken opkg package creation

[Richard Purdie]

Signed-off-by: Richard Purdie 
---
 .../opkg-utils/opkg-utils/pipefail.patch  | 31 +++
 .../opkg-utils/opkg-utils_0.4.1.bb|  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 meta/recipes-devtools/opkg-utils/opkg-utils/pipefail.patch

diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils/pipefail.patch 
b/meta/recipes-devtools/opkg-utils/opkg-utils/pipefail.patch
new file mode 100644
index 000..55ddcc1fd20
--- /dev/null
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils/pipefail.patch
@@ -0,0 +1,31 @@
+We need opkg-build to fail if for example the tar command is passed invalid 
+options. Without this, we see silently created empty packaged where data.tar
+is zero bytes in size. This creates hard to debug problems.
+
+An example is when reproducible builds are enabled and run on old hosts like
+centos7 which has tar < 1.28:
+
+Subprocess output:tar: unrecognized option '--clamp-mtime'
+Try `tar --help' or `tar --usage' for more information.
+
+Upstream-Status: Pending
+Signed-off-by: Richard Purdie 
+
+Index: opkg-utils-0.4.1/opkg-build
+===
+--- opkg-utils-0.4.1.orig/opkg-build
 opkg-utils-0.4.1/opkg-build
+@@ -1,4 +1,4 @@
+-#!/bin/sh
++#!/bin/bash
+ 
+ : <<=cut
+ =head1 NAME
+@@ -12,6 +12,7 @@ opkg-build - construct an .opk from a di
+ #   Updated to work on Familiar Pre0.7rc1, with busybox tar.
+ #   Note it Requires: binutils-ar (since the busybox ar can't create)
+ set -e
++set -o pipefail
+ 
+ version=1.0
+ 
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb 
b/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb
index cf1e4670c65..2e6e0f2760e 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb
@@ -10,6 +10,7 @@ PROVIDES += "${@bb.utils.contains('PACKAGECONFIG', 
'update-alternatives', 'virtu
 SRC_URI = 
"http://git.yoctoproject.org/cgit/cgit.cgi/${BPN}/snapshot/${BPN}-${PV}.tar.gz \
file://0001-Switch-all-scripts-to-use-Python-3.x.patch \
file://0001-opkg-build-clamp-mtimes-to-SOURCE_DATE_EPOCH.patch \
+   file://pipefail.patch \
 "
 UPSTREAM_CHECK_URI = 
"http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/refs/;
 
-- 
2.20.1

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

[OE-core] [PATCH] gstreamer1.0-plugins-bad: add PACKAGECONFIG option for zbar

[Norbert Wesp]

As a recipe for zbar was added 2016-12-26,
we can add an option in PACKAGECONFIG for it.

Signed-off-by: Norbert Wesp 
---
 .../gstreamer/gstreamer1.0-plugins-bad_1.16.1.bb  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.1.bb
index 1731be84410..ed3efab29fe 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.1.bb
@@ -82,12 +82,13 @@ PACKAGECONFIG[wayland] = 
"--enable-wayland,--disable-wayland,wayland-nat
 PACKAGECONFIG[webp]= "--enable-webp,--disable-webp,libwebp"
 PACKAGECONFIG[webrtc]  = "--enable-webrtc,--disable-webrtc,libnice"
 PACKAGECONFIG[webrtcdsp]   = 
"--enable-webrtcdsp,--disable-webrtcdsp,webrtc-audio-processing"
+PACKAGECONFIG[zbar]= "--enable-zbar,--disable-zbar,zbar"
 
 # these plugins have no corresponding library in OE-core or meta-openembedded:
 #   openni2 winks direct3d directsound winscreencap apple_media iqa
 #   android_media avc bs2b chromaprint dts fdkaac gme gsm kate ladspa
 #   lv2 mpeg2enc mplex musepack nvenc ofa opensles soundtouch
-#   spandsp teletextdec vdpau wasapi wpe x265 zbar
+#   spandsp teletextdec vdpau wasapi wpe x265
 
 EXTRA_OECONF += " \
 --enable-decklink \
@@ -131,7 +132,6 @@ EXTRA_OECONF += " \
 --disable-winscreencap \
 --disable-wpe \
 --disable-x265 \
---disable-zbar \
 ${@bb.utils.contains("TUNE_FEATURES", "mx32", "--disable-yadif", "", d)} \
 "
 
-- 
2.17.1

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

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

[André Draszik]

Hi,

On Wed, 2019-11-20 at 22:36 -0800, Tim Orling wrote:
> 
> 
> > On Nov 20, 2019, at 10:27 PM, Tim Orling  
> > wrote:
> > 
> > 
> > 
> > > On Nov 20, 2019, at 1:33 AM, Jean-Marie LEMETAYER 
> > >  wrote:
> > > 
> > > The current NPM support have several issues:
> > > - The current NPM fetcher downloads the dependency tree but not the other
> > >   fetchers. The 'subdir' parameter was used to fix this issue.
> > > - They are multiple issues with package names (uppercase, exotic 
> > > characters,
> > >   scoped packages) even if they are inside the dependencies.
> > > - The lockdown file generation have issues. When a package depends on
> > >   multiple version of the same package (all versions have the same 
> > > checksum).
> > > 
> > > This patchset refactors the NPM support in Yocto:
> > > - As the NPM algorithm for dependency management is hard to handle, the 
> > > new
> > >   NPM fetcher downloads only the package source (and not the dependencies,
> > >   like the other fetchers) (patch submitted in the bitbake-devel list).
> > > - The NPM class handles the dependencies using NPM (and not manually).
> > > - The NPM recipe creation is simplified to avoid issues.
> > > - The lockdown file is no more used as it is no longer relevant compared 
> > > to the
> > >   latest shrinkwrap file format.
> > > 
> > > This patchset may remove some features (lockdown file, license management 
> > > for
> > > dependencies) but fixes the majority of the NPM issues. All of these 
> > > issues
> > > from the bugzilla.yoctoproject.org are resolved by this patchset:
> > > #10237, #10760, #11028, #11728, #11902, #12534
> > > 
> > > The fetcher and recipetool are now aware of a 'latest' keyword for the 
> > > version
> > > which allow to build the latest version available on the registry. This 
> > > feature
> > > fixes the two issues: #10515, #11029
> > > 
> > > Moreover the issue #13415 should also be fixed but I cannot test it.
> > > 
> > > I have tested the recipe creation and builds using a self made example to
> > > generate build failures:
> > > - https://github.com/savoirfairelinux/node-server-example
> > > - https://npmjs.com/package/@savoirfairelinux/node-server-example
> > > 
> > > The test steps are these ones:
> > >  $ source poky/oe-init-build-env
> > >  $ bitbake-layers add-layer ../meta-openembedded/meta-oe
> > >  $ devtool add 
> > > "npm://registry.npmjs.org;name=@savoirfairelinux/node-server-example;version=latest”
> > 
> > I noticed this before but forgot to report it:
> > 
> > ERROR: Nothing PROVIDES 'c-ares-native' (but 
> > virtual:native:/build/meta-openembedded/meta-oe/recipes-
> > devtools/nodejs/nodejs_10.17.0.bb DEPENDS on or otherwise requires it). ...
> > http://layers.openembedded.org/layerindex/recipe/50318/
> > $ bitbake-layers add-layer ../meta-openembedded/meta-networking
> > Which requires
> > $ bitbake-layers add-layer ../meta-openembedded/meta-python
> > 
> > 
> > Using tip of bitbake with V3, openembedded-core with V3 and 
> > meta-openembedded master, somehow nodejs-native
> > do_compile broke (at least on qemux86-64) since the last time I built it 
> > shortly after ELC-E…
> > So now I’ll have to git bisect that…more to come…
> 
> See https://errors.yoctoproject.org/Errors/Details/274939/
> The same error I am seeing.

Might be caused by 0005-Link-atomic-library.patch which unconditionally makes it
link against libatomic.so
I'd say this should be done conditionally on those arches that need it, 
exclusively.
Ideally using some kind of auto-detection...

Not sure why it's a problem only now, though.

Cheers,
Andre'

> 
> > FWIW I had previously successfully run your instructions and the tests for 
> > both bitbake and oe-selftest for V2
> > (distroless, e.g. not with poky). Something unrelated has broken I suspect.
> > 
> > >  $ devtool build savoirfairelinux-node-server-example
> > >  $ bitbake-layers create-layer ../meta-test
> > >  $ bitbake-layers add-layer ../meta-test
> > >  $ devtool finish savoirfairelinux-node-server-example ../meta-test
> > >  $ echo IMAGE_INSTALL_append = '" savoirfairelinux-node-server-example"' 
> > > >> conf/local.conf
> > >  $ bitbake core-image-minimal
> > > 
> > > Also the 'devtool add' url could be one of these:
> > > - 
> > > npm://registry.npmjs.org;name=@savoirfairelinux/node-server-example;version=latest
> > >   This url uses the new npm fetcher and request the latest version 
> > > available on
> > >   the registry.
> > > - 
> > > npm://registry.npmjs.org;name=@savoirfairelinux/node-server-example;version=1.0.0
> > >   This url uses the new npm fetcher and request a fixed version.
> > > - git://github.com/savoirfairelinux/node-server-example.git;protocol=https
> > >   This url uses the git fetcher. As the dependencies are managed by the 
> > > NPM
> > >   class, any fetcher can be used.
> > > 
> > > When this patchset will be merged, I have planned to update the NPM wiki:
> > >  https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM
> > > 
> 

[OE-core] [PATCH] pulseaudio: 12.2 -> 13.0

[Tanu Kaskinen]

Release notes:
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/13.0/

Dropped intltool-native from DEPENDS. The .desktop file translations
don't need intltool any more, gettext is enough.

Dropped upstreamed patches:
0001-alsa-Fix-inclusion-of-use-case.h.patch
0001-introduce-a-special-build-flag-to-explicitly-disable.patch

Added a new package: pulseaudio-pa-info. It contains the new pa-info
script.

BlueZ 4 support was removed in this version. That's not visible in the
recipe, but I noticed that the BlueZ 4 modules were still being built in
12.2, since they hadn't been explicitly disabled in the recipe.

Signed-off-by: Tanu Kaskinen 
---
 .../pulseaudio/pulseaudio.inc |  27 ++-
 ...001-alsa-Fix-inclusion-of-use-case.h.patch |  46 -
 ...ial-build-flag-to-explicitly-disable.patch | 161 --
 ...{pulseaudio_12.2.bb => pulseaudio_13.0.bb} |   6 +-
 4 files changed, 26 insertions(+), 214 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-alsa-Fix-inclusion-of-use-case.h.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-introduce-a-special-build-flag-to-explicitly-disable.patch
 rename meta/recipes-multimedia/pulseaudio/{pulseaudio_12.2.bb => 
pulseaudio_13.0.bb} (58%)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index ec51d8b279..4e32b27087 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -56,7 +56,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=0e5cd938de1a7a53ea5adac38cc10c39 \
 
file://src/pulsecore/filter/biquad.h;beginline=1;endline=4;md5=6d46d1365206528a20137355924233c1
 \
 "
 
-DEPENDS = "libatomic-ops libsndfile1 libtool intltool-native"
+DEPENDS = "libatomic-ops libsndfile1 libtool"
 # optional
 DEPENDS += "udev alsa-lib glib-2.0"
 DEPENDS += "speexdsp libxml-parser-perl-native libcap"
@@ -158,12 +158,22 @@ USERADD_PARAM_pulseaudio-server = "--system --home 
/var/run/pulse \
   --no-create-home --shell /bin/false \
   --groups audio,pulse --gid pulse pulse"
 
+PACKAGES =+ "\
+ libpulse \
+ libpulse-mainloop-glib \
+ libpulse-simple \
+ libpulsecommon \
+ libpulsecore \
+ ${PN}-pa-info \
+ ${PN}-server \
+ ${PN}-misc \
+ "
+
 # The console-kit module is included here explicitly so bitbake can map to the
 # RDEPENDS we define for it in this recipe, and thereby ensure that when
 # adding the console-kit module to an image, we also get the necessary
 # consolekit package produced.
-PACKAGES =+ "libpulsecore libpulsecommon libpulse libpulse-simple 
libpulse-mainloop-glib \
- pulseaudio-server pulseaudio-misc 
${@bb.utils.contains('PACKAGECONFIG', 'dbus', 'pulseaudio-module-console-kit', 
'', d)}"
+PACKAGES =+ "${@bb.utils.contains('PACKAGECONFIG', 'dbus', 
'pulseaudio-module-console-kit', '', d)}"
 
 #upgrade path:
 RREPLACES_pulseaudio-server = "libpulse-bin libpulse-conf"
@@ -183,6 +193,7 @@ FILES_libpulse-mainloop-glib = 
"${libdir}/libpulse-mainloop-glib.so.*"
 FILES_${PN}-dev += "${libdir}/pulse-${PV}/modules/*.la ${datadir}/vala 
${libdir}/cmake"   
 FILES_${PN}-conf = "${sysconfdir}"
 FILES_${PN}-bin += "${sysconfdir}/default/volatiles/volatiles.04_pulse"
+FILES_${PN}-pa-info = "${bindir}/pa-info"
 FILES_${PN}-server = "${bindir}/pulseaudio ${bindir}/start-* ${sysconfdir} 
${bindir}/pactl */udev/rules.d/*.rules */*/udev/rules.d/*.rules 
${systemd_user_unitdir}/*"
 
 #SYSTEMD_PACKAGES = "${PN}-server"
@@ -214,6 +225,16 @@ python populate_packages_prepend() {
 do_split_packages(d, plugindir, r'^lib(.*)\.so$', '${PN}-lib-%s', 
'PulseAudio library for %s', extra_depends='', prepend=True)
 }
 
+# pa-info is a bash script that collects information about the audio setup.
+# It's primarily useful for attaching an information dump when reporting bugs.
+RDEPENDS_${PN}-pa-info = "\
+  alsa-utils-amixer \
+  alsa-utils-aplay \
+  alsa-utils-scripts \
+  bash \
+  ${PN}-server \
+  "
+
 RDEPENDS_pulseaudio-server = " \
 pulseaudio-module-filter-apply \
 pulseaudio-module-filter-heuristics \
diff --git 
a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-alsa-Fix-inclusion-of-use-case.h.patch
 
b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-alsa-Fix-inclusion-of-use-case.h.patch
deleted file mode 100644
index 15026a2f83..00
--- 
a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-alsa-Fix-inclusion-of-use-case.h.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From b89d33bb182c42db5ad3987b0e91b7bf62f421e8 Mon Sep 17 00:00:00 2001
-From: Takashi Iwai 
-Date: Sun, 21 Apr 2019 11:59:30 +0200
-Subject: [PATCH] alsa: Fix 

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

[Phil Blundell]

On Thu, Nov 21, 2019 at 10:10:30AM +, Richard Purdie wrote:
> On Thu, 2019-11-21 at 09:24 +, Ross Burton wrote:
> > 2) the source is positively ancient and building it on modern linux is 
> > getting harder over time

Just to put this in perspective, I tried fetching lrzsz-1.20.0.tar.gz
from the upstream site, unpacked it on my Debian "buster" host, did
"./configure && make" without modifying any files, and it built 
absolutely fine using gcc-8.3.0.  There were a few compiler warnings
but nothing worse than that.  

Now, I am happy to accept that building it inside oe-core is somewhat 
more difficult, and regenerating the autotools bits using modern tools
does look like it will require some patching, but I don't think we should
exaggerate the extent to which "old code" equals "problematic code".

> I just wanted to highlight that the way things are trending, its likely
> we'll end up with Linux builds alongside RTOS builds with multiconfig.
> These will likely need to communicate and the mechanism(s) for that
> remain to be seen.

meta-oe has a recipe for kermit... :-}

> over into Linux. I therefore have a slight inclination to try and keep
> this around if we can.
> 
> I do take the point about needing work to keep it maintained/working
> though :(.

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

I have no particular opinion as to whether it ought to stay in oe-core
or move into some sort of meta-retrocomputing layer.

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

Re: [OE-core] How to backport openssl to Sumo

[Ryan Harkin]

On Thu, 21 Nov 2019 at 13:39, Nicolas Dechesne 
wrote:

> On Thu, Nov 21, 2019 at 2:15 PM Ryan Harkin 
> wrote:
> >
> >
> >
> > On Wed, 20 Nov 2019 at 23:53, Andre McCurdy  wrote:
> >>
> >> On Wed, Nov 20, 2019 at 2:41 PM Ryan Harkin 
> wrote:
> >> > On Wed, 20 Nov 2019 at 21:29, Ryan Harkin 
> wrote:
> >> >>
> >> >> I pulled the whole openssl dir from your repo, added the layer.conf
> changes to my layer.conf and rebuilt openssl and my image.
> >> >>
> >> >> Unfortunately, I still have no /usr/bin/openssl in my disk image. So
> I've added the RPROVIDES from Andre's in a vain attempt to get it to work:
> >> >>
> >> >> RPROVIDES_${PN} += "openssl-bin"
> >> >>
> >> >> ... although I'm not hopeful it'll do the trick...
> >> >
> >> > It didn't work. Once thing that's puzzling me: where is the package
> "openssl-bin"? I can only find references to it, but no package.
> >>
> >> The "openssl-bin" package is created by the openssl 1.1.x recipe.
> >>
> >> Adding "openssl-bin" to RPROVIDES in the openssl 1.0.2 recipe is a
> >> solution for users who are switching from openssl 1.1.x back to 1.0.2
> >> and have an image which is tries to include the new openssl-bin
> >> package. I don't think that's what you are trying to do (?).
> >
> >
> > Correct. I only tried it because the 1.0.2t recipe wasn't working.
> >
> > To be clear - I have /usr/bin/openssl in my image when using 1.0.2p from
> the Poky Sumo branch. When I add the 1.0.2t recipe to my own layer, openssl
> builds without errors, but I don't get the binary.
> >
> >>
> >> If you are using openssl 1.0.2 then the openssl command line tool is
> >> in the openssl package... so to include the openssl command line tool,
> >> add the "openssl" package to your image.
> >>
> >> If you are using openssl 1.1.x then the openssl command line tool is
> >> in the openssl-bin package... so to include the openssl command line
> >> tool, add the "openssl-bin" package to your image.
> >>
> >> But anyway, in all cases, the way to debug what's going on isn't to
> >> try random recipe changes and then rebuild the final image. Instead
> >> you should build your chosen version of openssl, look in the
> >> packages-split directory to see which package includes the openssl
> >> command line tool and then add that package to your image.
> >
> >
> > I don't have a packages-split. I was unaware of it, and reading the
> manual, it seems I should have one. But I don't. Running 'bitbake -e
> openssl | grep "PKGDEST="' tells me I should have one, but there are no
> instances in a directory called "packages-split" in my tmp dir.
>
> most likely because you are using rm_work.
>

Yes, I am! Thanks, Nico.


>
> >
> > Anyway, I'm giving up for now. I'll come back to another time... or more
> likely, get someone smarter than me to sort it out ;-)
> > --
> > ___
> > 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] How to backport openssl to Sumo

[Nicolas Dechesne]

On Thu, Nov 21, 2019 at 2:15 PM Ryan Harkin  wrote:
>
>
>
> On Wed, 20 Nov 2019 at 23:53, Andre McCurdy  wrote:
>>
>> On Wed, Nov 20, 2019 at 2:41 PM Ryan Harkin  wrote:
>> > On Wed, 20 Nov 2019 at 21:29, Ryan Harkin  wrote:
>> >>
>> >> I pulled the whole openssl dir from your repo, added the layer.conf 
>> >> changes to my layer.conf and rebuilt openssl and my image.
>> >>
>> >> Unfortunately, I still have no /usr/bin/openssl in my disk image. So I've 
>> >> added the RPROVIDES from Andre's in a vain attempt to get it to work:
>> >>
>> >> RPROVIDES_${PN} += "openssl-bin"
>> >>
>> >> ... although I'm not hopeful it'll do the trick...
>> >
>> > It didn't work. Once thing that's puzzling me: where is the package 
>> > "openssl-bin"? I can only find references to it, but no package.
>>
>> The "openssl-bin" package is created by the openssl 1.1.x recipe.
>>
>> Adding "openssl-bin" to RPROVIDES in the openssl 1.0.2 recipe is a
>> solution for users who are switching from openssl 1.1.x back to 1.0.2
>> and have an image which is tries to include the new openssl-bin
>> package. I don't think that's what you are trying to do (?).
>
>
> Correct. I only tried it because the 1.0.2t recipe wasn't working.
>
> To be clear - I have /usr/bin/openssl in my image when using 1.0.2p from the 
> Poky Sumo branch. When I add the 1.0.2t recipe to my own layer, openssl 
> builds without errors, but I don't get the binary.
>
>>
>> If you are using openssl 1.0.2 then the openssl command line tool is
>> in the openssl package... so to include the openssl command line tool,
>> add the "openssl" package to your image.
>>
>> If you are using openssl 1.1.x then the openssl command line tool is
>> in the openssl-bin package... so to include the openssl command line
>> tool, add the "openssl-bin" package to your image.
>>
>> But anyway, in all cases, the way to debug what's going on isn't to
>> try random recipe changes and then rebuild the final image. Instead
>> you should build your chosen version of openssl, look in the
>> packages-split directory to see which package includes the openssl
>> command line tool and then add that package to your image.
>
>
> I don't have a packages-split. I was unaware of it, and reading the manual, 
> it seems I should have one. But I don't. Running 'bitbake -e openssl | grep 
> "PKGDEST="' tells me I should have one, but there are no instances in a 
> directory called "packages-split" in my tmp dir.

most likely because you are using rm_work.

>
> Anyway, I'm giving up for now. I'll come back to another time... or more 
> likely, get someone smarter than me to sort it out ;-)
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Jean-Marie LEMETAYER]

Hi Tim,

On Nov 21, 2019, at 7:36 AM, Tim Orling timothy.t.orl...@linux.intel.com wrote:
>> On Nov 20, 2019, at 10:27 PM, Tim Orling 
>> wrote:
>>> On Nov 20, 2019, at 1:33 AM, Jean-Marie LEMETAYER
>>> >> > wrote:
>>> 
>>> The test steps are these ones:
>>>  $ source poky/oe-init-build-env
>>>  $ bitbake-layers add-layer ../meta-openembedded/meta-oe
>>>  $ devtool add
>>>  
>>> "npm://registry.npmjs.org;name=@savoirfairelinux/node-server-example;version=latest
>>>  
>>> ”
>> 
>> I noticed this before but forgot to report it:
>> 
>> ERROR: Nothing PROVIDES 'c-ares-native' (but
>> virtual:native:/build/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_10.17.0.bb
>> DEPENDS on or otherwise requires it). ...
>> http://layers.openembedded.org/layerindex/recipe/50318/
>> 
>> $ bitbake-layers add-layer ../meta-openembedded/meta-networking
>> Which requires
>> $ bitbake-layers add-layer ../meta-openembedded/meta-python
>> 
>> 
>> Using tip of bitbake with V3, openembedded-core with V3 and meta-openembedded
>> master, somehow nodejs-native do_compile broke (at least on qemux86-64) since
>> the last time I built it shortly after ELC-E…
>> So now I’ll have to git bisect that…more to come…
> 
> See https://errors.yoctoproject.org/Errors/Details/274939/
> 
> The same error I am seeing.
> 
>> 
>> FWIW I had previously successfully run your instructions and the tests for 
>> both
>> bitbake and oe-selftest for V2 (distroless, e.g. not with poky). Something
>> unrelated has broken I suspect.

Thanks for your feedback.

Since ELCE the nodejs recipe have received some patches including this one:
http://lists.openembedded.org/pipermail/openembedded-devel/2019-October/202636.html

And was updated to 10.17.0:
http://lists.openembedded.org/pipermail/openembedded-devel/2019-October/202639.html

But since it is concerning the nodejs recipe and not the npm fetcher/class
do you think it should block the patchset ?

>>>  $ devtool build savoirfairelinux-node-server-example
>>>  $ bitbake-layers create-layer ../meta-test
>>>  $ bitbake-layers add-layer ../meta-test
>>>  $ devtool finish savoirfairelinux-node-server-example ../meta-test
>>>  $ echo IMAGE_INSTALL_append = '" savoirfairelinux-node-server-example"' >>
>>>  conf/local.conf
>>>  $ bitbake core-image-minimal
>>> 
>>> --- V2
>>> 
>>> - Add a 'recipetool.RecipetoolTests.test_recipetool_create_npm' test case 
>>> for
>>>   'oe-selftest' to test the npm recipe creation.
>>> 
>>> --- V3
>>> 
>>> - Add a test regarding the 'devtool add' and 'devtool build' command:
>>> - devtool.DevtoolAddTests.test_devtool_add_npm

I had a lot of requests about tests. What do you think about these ?
FYI some fetcher tests have also been posted in the bitbake mailing list.

Regards,
Jean-Marie




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

Re: [OE-core] How to backport openssl to Sumo

[Ryan Harkin]

On Wed, 20 Nov 2019 at 23:53, Andre McCurdy  wrote:

> On Wed, Nov 20, 2019 at 2:41 PM Ryan Harkin 
> wrote:
> > On Wed, 20 Nov 2019 at 21:29, Ryan Harkin 
> wrote:
> >>
> >> I pulled the whole openssl dir from your repo, added the layer.conf
> changes to my layer.conf and rebuilt openssl and my image.
> >>
> >> Unfortunately, I still have no /usr/bin/openssl in my disk image. So
> I've added the RPROVIDES from Andre's in a vain attempt to get it to work:
> >>
> >> RPROVIDES_${PN} += "openssl-bin"
> >>
> >> ... although I'm not hopeful it'll do the trick...
> >
> > It didn't work. Once thing that's puzzling me: where is the package
> "openssl-bin"? I can only find references to it, but no package.
>
> The "openssl-bin" package is created by the openssl 1.1.x recipe.
>
> Adding "openssl-bin" to RPROVIDES in the openssl 1.0.2 recipe is a
> solution for users who are switching from openssl 1.1.x back to 1.0.2
> and have an image which is tries to include the new openssl-bin
> package. I don't think that's what you are trying to do (?).
>

Correct. I only tried it because the 1.0.2t recipe wasn't working.

To be clear - I have /usr/bin/openssl in my image when using 1.0.2p from
the Poky Sumo branch. When I add the 1.0.2t recipe to my own layer, openssl
builds without errors, but I don't get the binary.


> If you are using openssl 1.0.2 then the openssl command line tool is
> in the openssl package... so to include the openssl command line tool,
> add the "openssl" package to your image.
>
> If you are using openssl 1.1.x then the openssl command line tool is
> in the openssl-bin package... so to include the openssl command line
> tool, add the "openssl-bin" package to your image.
>
> But anyway, in all cases, the way to debug what's going on isn't to
> try random recipe changes and then rebuild the final image. Instead
> you should build your chosen version of openssl, look in the
> packages-split directory to see which package includes the openssl
> command line tool and then add that package to your image.
>

I don't have a packages-split. I was unaware of it, and reading the manual,
it seems I should have one. But I don't. Running 'bitbake -e openssl | grep
"PKGDEST="' tells me I should have one, but there are no instances in a
directory called "packages-split" in my tmp dir.

Anyway, I'm giving up for now. I'll come back to another time... or more
likely, get someone smarter than me to sort it out ;-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to disable menuconfig logic

[Tom Hochstein]

> -Original Message-
> From: Peter Kjellerstedt 
> Sent: Thursday, November 21, 2019 4:24 AM
> To: Tom Hochstein ; 
> openembedded-core@lists.openembedded.org
> Subject: RE: [OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to 
> disable menuconfig logic
> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org  > boun...@lists.openembedded.org> On Behalf Of Tom Hochstein
> > Sent: den 20 november 2019 20:26
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to
> > disable menuconfig logic
> >
> > @@ -940,8 +940,10 @@ def modify(args, config, basepath, workspace):
> >  '}\n')
> >  if rd.getVarFlag('do_menuconfig','task'):
> >  f.write('\ndo_configure_append() {\n'
> > -'cp ${B}/.config ${S}/.config.baseline\n'
> > -'ln -sfT ${B}/.config ${S}/.config.new\n'
> > +'if [ ! ${DEVTOOL_DISABLE_MENUCONFIG} ]; then\n'
> > +'cp ${B}/.config ${S}/.config.baseline\n'
> > +'ln -sfT ${B}/.config ${S}/.config.new\n'
> > +'fi\n'
> 
> Why do you need the extra variable? Why not just check if the .config
> file exists before copying it:
> 
> 'if -e ${B}/.config; then\n'
> 'cp ${B}/.config ${S}/.config.baseline\n'
> 'ln -sfT ${B}/.config ${S}/.config.new\n'
> 'fi\n'
> 
> >  '}\n')
> >  if initial_rev:
> >  f.write('\n# initial_rev: %s\n' % initial_rev)
> > --
> > 2.17.1
> 
> //Peter

I wanted to preserve the existing error handling in the case that menuconfig is 
supported and .config is unexpectedly missing. Having the cp fail immediately 
seems best.

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

[OE-core] ✗ patchtest: failure for "[meta-oe] openct: merge do_ins..." and 5 more

[Patchwork]

== Series Details ==

Series: "[meta-oe] openct: merge do_ins..." and 5 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/21281/
State : failure

== Summary ==


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



* Patch[meta-oe,1/6] openct: merge do_install and do_install_append
 Issue Series sent to the wrong mailing list 
[test_target_mailing_list] 
  Suggested fixCheck the project's README (meta-oe,1/6) and send the patch 
to the indicated list

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



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [meta-oe][PATCH 5/6] libp11: add support for native builds

[Jan Luebbe]

This is needed as a dependency when using SoftHSM from the PKCS#11
OpenSSL engine for code singing.

Signed-off-by: Jan Luebbe 
---
 meta-oe/recipes-support/libp11/libp11_0.4.10.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-oe/recipes-support/libp11/libp11_0.4.10.bb 
b/meta-oe/recipes-support/libp11/libp11_0.4.10.bb
index b40223e8abcb..fc2ec9935f56 100644
--- a/meta-oe/recipes-support/libp11/libp11_0.4.10.bb
+++ b/meta-oe/recipes-support/libp11/libp11_0.4.10.bb
@@ -24,3 +24,5 @@ do_install_append () {
 
 FILES_${PN} += "${libdir}/engines*/pkcs11.so"
 FILES_${PN}-dev += "${libdir}/engines*/libpkcs11${SOLIBSDEV}"
+
+BBCLASSEXTEND="native"
-- 
2.24.0

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

[OE-core] [meta-oe][PATCH 4/6] opensc: add support for native builds

[Jan Luebbe]

This is needed as a dependency when using SoftHSM from the PKCS#11
OpenSSL engine for code singing.

Signed-off-by: Jan Luebbe 
---
 meta-oe/recipes-support/opensc/opensc_0.19.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-oe/recipes-support/opensc/opensc_0.19.0.bb 
b/meta-oe/recipes-support/opensc/opensc_0.19.0.bb
index 440859a37a93..6354ca3f48ff 100644
--- a/meta-oe/recipes-support/opensc/opensc_0.19.0.bb
+++ b/meta-oe/recipes-support/opensc/opensc_0.19.0.bb
@@ -45,3 +45,5 @@ FILES_${PN}-dev += "\
 ${libdir}/pkcs11/onepin-opensc-pkcs11.so \
 ${libdir}/pkcs11/pkcs11-spy.so \
 "
+
+BBCLASSEXTEND="native"
-- 
2.24.0

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

[OE-core] [meta-oe][PATCH 3/6] opensc: use pcsc-lite instead of openct by default

[Jan Luebbe]

OpenCT upstream maintenance seems to have stopped and OpenSC upstream
uses pcsc-lite by default in their configure script. Add PACKAGECONFIGs
for each and select pcsc by default.

As the openct package depends on pcsc-lite by itself, this avoids an
unnecessary package in the default case.

Signed-off-by: Jan Luebbe 
---
 meta-oe/recipes-support/opensc/opensc_0.19.0.bb | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta-oe/recipes-support/opensc/opensc_0.19.0.bb 
b/meta-oe/recipes-support/opensc/opensc_0.19.0.bb
index bc1722e394f6..440859a37a93 100644
--- a/meta-oe/recipes-support/opensc/opensc_0.19.0.bb
+++ b/meta-oe/recipes-support/opensc/opensc_0.19.0.bb
@@ -16,20 +16,23 @@ SRCREV = "f1691fc91fc113191c3a8aaf5facd6983334ec47"
 SRC_URI = "git://github.com/OpenSC/OpenSC \
file://0001-Remove-redundant-logging.patch \
   "
-DEPENDS = "openct pcsc-lite virtual/libiconv openssl"
+DEPENDS = "virtual/libiconv openssl"
 
 S = "${WORKDIR}/git"
 inherit autotools pkgconfig bash-completion
 
 EXTRA_OECONF = " \
 --disable-static \
---enable-openct \
---disable-pcsc \
 --disable-ctapi \
 --disable-doc \
 "
 EXTRA_OEMAKE = "DESTDIR=${D}"
 
+PACKAGECONFIG ??= "pcsc"
+
+PACKAGECONFIG[openct] = "--enable-openct,--disable-openct,openct"
+PACKAGECONFIG[pcsc] = "--enable-pcsc,--disable-pcsc,pcsc-lite"
+
 RDEPENDS_${PN} = "readline"
 
 FILES_${PN} += "\
-- 
2.24.0

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

[OE-core] [meta-oe][PATCH 1/6] openct: merge do_install and do_install_append

[Jan Luebbe]

There is no reason why both should be used in the same recipe. Merge
them.

Signed-off-by: Jan Luebbe 
---
 meta-oe/recipes-support/openct/openct_0.6.20.bb | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta-oe/recipes-support/openct/openct_0.6.20.bb 
b/meta-oe/recipes-support/openct/openct_0.6.20.bb
index 67b7c2975302..08b2e3c23236 100644
--- a/meta-oe/recipes-support/openct/openct_0.6.20.bb
+++ b/meta-oe/recipes-support/openct/openct_0.6.20.bb
@@ -56,10 +56,6 @@ FILES_${PN}-dbg += " \
 
 INSANE_SKIP_${PN} += "dev-deps"
 
-do_install_append() {
-rm -r ${D}/${localstatedir}/run
-}
-
 do_install () {
 rm -rf ${D}
 install -d ${D}/etc
@@ -87,4 +83,6 @@ do_install () {
 install -dm 755 ${D}${localstatedir}/run/openct
 touch ${D}${localstatedir}/run/openct/status
 chmod 644 ${D}${localstatedir}/run/openct/status
+
+rm -r ${D}/${localstatedir}/run
 }
-- 
2.24.0

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

[OE-core] [meta-oe][PATCH 2/6] pcsc-lite: add support for native builds

[Jan Luebbe]

This is needed as a dependency when using SoftHSM from the PKCS#11
OpenSSL engine for code singing.

Add a udev PACKAGECONFIG, as this is only useful on the target. Also
don't RRECOMMEND ccid for the native variant.

Signed-off-by: Jan Luebbe 
---
 meta-oe/recipes-support/pcsc-lite/pcsc-lite_1.8.25.bb | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta-oe/recipes-support/pcsc-lite/pcsc-lite_1.8.25.bb 
b/meta-oe/recipes-support/pcsc-lite/pcsc-lite_1.8.25.bb
index a87c228a8374..33f7f839cb1b 100644
--- a/meta-oe/recipes-support/pcsc-lite/pcsc-lite_1.8.25.bb
+++ b/meta-oe/recipes-support/pcsc-lite/pcsc-lite_1.8.25.bb
@@ -9,7 +9,6 @@ LICENSE_${PN}-dbg = "BSD & GPLv3+"
 LICENSE_${PN}-spy = "GPLv3+"
 LICENSE_${PN}-spy-dev = "GPLv3+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=628c01ba985ecfa21677f5ee2d5202f6"
-DEPENDS = "udev"
 
 SRC_URI = "https://pcsclite.apdu.fr/files/${BP}.tar.bz2;
 SRC_URI[md5sum] = "c20650a36062ab1689f37f3302c988f2"
@@ -19,19 +18,21 @@ inherit autotools systemd pkgconfig
 
 EXTRA_OECONF = " \
 --disable-libusb \
---enable-libudev \
 --enable-usbdropdir=${libdir}/pcsc/drivers \
 "
 
 S = "${WORKDIR}/pcsc-lite-${PV}"
 
-PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)}"
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} udev"
+PACKAGECONFIG_class-native ??= ""
 
 PACKAGECONFIG[systemd]  = ",--disable-libsystemd,systemd,"
+PACKAGECONFIG[udev] = "--enable-libudev,--disable-libudev,udev"
 
 PACKAGES = "${PN} ${PN}-dbg ${PN}-dev ${PN}-lib ${PN}-doc ${PN}-spy 
${PN}-spy-dev"
 
 RRECOMMENDS_${PN} = "ccid"
+RRECOMMENDS_${PN}_class-native = ""
 
 FILES_${PN} = "${sbindir}/pcscd"
 FILES_${PN}-lib = "${libdir}/libpcsclite*${SOLIBS}"
@@ -50,3 +51,5 @@ RREPLACES_${PN} += "${PN}-systemd"
 RCONFLICTS_${PN} += "${PN}-systemd"
 SYSTEMD_SERVICE_${PN} = "pcscd.socket"
 RDEPENDS_${PN}-spy +="python"
+
+BBCLASSEXTEND="native"
-- 
2.24.0

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

[OE-core] [meta-oe][PATCH 6/6] softhsm: add recipe

[Jan Luebbe]

This is useful for consolidation of code-signing interfaces when
building an image with verified boot mechanisms or signed update
artifacts. It can also be used on the target as a backend for software
which uses the PKCS#11 API to access private key material.

Signed-off-by: Jan Luebbe 
---
 .../recipes-security/softhsm/softhsm_git.bb| 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 meta-oe/recipes-security/softhsm/softhsm_git.bb

diff --git a/meta-oe/recipes-security/softhsm/softhsm_git.bb 
b/meta-oe/recipes-security/softhsm/softhsm_git.bb
new file mode 100644
index ..3236cb9a6097
--- /dev/null
+++ b/meta-oe/recipes-security/softhsm/softhsm_git.bb
@@ -0,0 +1,18 @@
+SUMMARY = "PKCS#11 HSM/Token Emulator"
+HOMEPAGE = "https://www.opendnssec.org/softhsm/;
+LICENSE = "BSD-2-Clause & ISC"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=ef3f77a3507c3d91e75b9f2bdaee4210"
+DEPENDS = "openssl"
+PV = "2.5.0"
+
+SRC_URI = "git://github.com/opendnssec/SoftHSMv2.git;branch=master"
+SRCREV = "369df0383d101bc8952692c2a368ac8bc887d1b4"
+
+S = "${WORKDIR}/git"
+
+inherit autotools pkgconfig
+
+# EdDSA requires OpenSSL >= 1.1.1
+EXTRA_OECONF = "--enable-eddsa --disable-gost"
+
+BBCLASSEXTEND = "native"
-- 
2.24.0

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

Re: [OE-core] [PATCH] tiff: Refresh patch

[Ross Burton]

On 21/11/2019 08:44, Zheng Ruoqin wrote:

Refresh CVE-2019-7663.patch as it can't be applyed when using PATCHTOOL = 
"patch".


FWIW this file is removed in current master-next.

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

Re: [OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to disable menuconfig logic

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  boun...@lists.openembedded.org> On Behalf Of Tom Hochstein
> Sent: den 20 november 2019 20:26
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 1/2] devtool/standard.py: Allow recipe to
> disable menuconfig logic
> 
> u-boot.inc supports u-boot recipes with or without menuconfig [1].
> However, running devtool on a u-boot recipe that does not support
> menuconfig
> results in an error:
> 
> cp: cannot stat '/home/r60874/upstream/fsl-xwayland/tmp/work/imx8mmevk-
> fsl-linux/u-boot-imx/2018.03-r0/u-boot-imx-2018.03//.config': No such file
> or directory
> 
> The problem is the devtool logic assumes that any recipe with a
> do_menuconfig task
> will generate a .config in do_configure().
> 
> Fix the problem by removing the assumption with a flag that the recipe can
> control,
> like this:
> 
> do_configure() {
> if [ menuconfig-supported ]; then
> ...
> else
> DEVTOOL_DISABLE_MENUCONFIG=true
> fi
> }
> 
> [1] https://github.com/openembedded/openembedded-
> core/commit/11278e3b2c75be80645b9841763a97dbb35daadc
> 
> Signed-off-by: Tom Hochstein 
> ---
>  scripts/lib/devtool/standard.py | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/lib/devtool/standard.py
> b/scripts/lib/devtool/standard.py
> index 8d9c1a3022..66bd1415c3 100644
> --- a/scripts/lib/devtool/standard.py
> +++ b/scripts/lib/devtool/standard.py
> @@ -940,8 +940,10 @@ def modify(args, config, basepath, workspace):
>  '}\n')
>  if rd.getVarFlag('do_menuconfig','task'):
>  f.write('\ndo_configure_append() {\n'
> -'cp ${B}/.config ${S}/.config.baseline\n'
> -'ln -sfT ${B}/.config ${S}/.config.new\n'
> +'if [ ! ${DEVTOOL_DISABLE_MENUCONFIG} ]; then\n'
> +'cp ${B}/.config ${S}/.config.baseline\n'
> +'ln -sfT ${B}/.config ${S}/.config.new\n'
> +'fi\n'

Why do you need the extra variable? Why not just check if the .config 
file exists before copying it:

'if -e ${B}/.config; then\n'
'cp ${B}/.config ${S}/.config.baseline\n'
'ln -sfT ${B}/.config ${S}/.config.new\n'
'fi\n'

>  '}\n')
>  if initial_rev:
>  f.write('\n# initial_rev: %s\n' % initial_rev)
> --
> 2.17.1

//Peter

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

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

[Richard Purdie]

On Thu, 2019-11-21 at 09:24 +, Ross Burton wrote:
> On 20/11/2019 23:18, Adrian Bunk wrote:
> > On Wed, Nov 20, 2019 at 11:56:38PM +0100, Alexander Kanavin wrote:
> > > On Wed, 20 Nov 2019 at 23:32, Phil Blundell  wrote:
> > > 
> > > > However, I think the point still stands that the commit message needs to
> > > > provide a better description of why the package is being removed.  If 
> > > > you
> > > > think it represents an ongoing maintenance headache that's already bad 
> > > > and
> > > > only going to get worse, and this now outweighs its usefulness, let's 
> > > > just
> > > > say that.  Not all old software is problematic, and not all problematic
> > > > software is old; the fact that the last release was 20 years ago is an
> > > > interesting fact but in isolation that doesn't represent a problem.
> > > > Indeed, compared to some other packages in oe-core, eight patches in
> > > > total over a 20-year period doesn't seem like that bad of an average.
> > > > 
> > > 
> > > Fair enough, I wrote a hasty commit message. Mistakes happen.
> > > 
> > > Can I say what my problem is? Here goes: so far, no one in this discussion
> > > offered actual help with the actual issue. If you need this or that
> > > functionality from Yocto, please try to place help ahead of complaints and
> > > criticism.
> > 
> > No, your problem is your way of communication.
> > 
> > It is a very unfriendly way of communication to request help in the form
> > patch aiming at immediate removal.
> 
> Hopefully everyone has calmed down overnight and we can continue this 
> discussion politely?

Agreed, lets keep this level headed!

> Yes, Alex's commit message should have spelt out that both:
> 1) there are doubts anyone is actually using zmodem still (he did this)
> 2) the source is positively ancient and building it on modern linux is 
> getting harder over time (this was implied by being in a series that 
> upgraded gettext and fixed other recipes, instead of being spelt out).
> 
> So, if zmodem is still a useful feature to have in core, then is anyone 
> willing to step up and either:
> 1) maintain the recipe.  I'd love someone who uses lrzsz to put a fork 
> up on github, integrate all of our patches, and start maintaining it. 
> Maybe then other distributions who still ship it will join in too.
> 2) provide an alternative.

I just wanted to highlight that the way things are trending, its likely
we'll end up with Linux builds alongside RTOS builds with multiconfig.
These will likely need to communicate and the mechanism(s) for that
remain to be seen. I know I've personally implemented xmodem and then
ymodem as a way of dumping data out a microcontroller on a small
project before, it makes for a simple/effective way of getting data
over into Linux. I therefore have a slight inclination to try and keep
this around if we can.

I do take the point about needing work to keep it maintained/working
though :(.

Cheers,

Richard



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

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

[Ross Burton]

On 20/11/2019 23:18, Adrian Bunk wrote:

On Wed, Nov 20, 2019 at 11:56:38PM +0100, Alexander Kanavin wrote:

On Wed, 20 Nov 2019 at 23:32, Phil Blundell  wrote:


However, I think the point still stands that the commit message needs to
provide a better description of why the package is being removed.  If you
think it represents an ongoing maintenance headache that's already bad and
only going to get worse, and this now outweighs its usefulness, let's just
say that.  Not all old software is problematic, and not all problematic
software is old; the fact that the last release was 20 years ago is an
interesting fact but in isolation that doesn't represent a problem.
Indeed, compared to some other packages in oe-core, eight patches in
total over a 20-year period doesn't seem like that bad of an average.



Fair enough, I wrote a hasty commit message. Mistakes happen.

Can I say what my problem is? Here goes: so far, no one in this discussion
offered actual help with the actual issue. If you need this or that
functionality from Yocto, please try to place help ahead of complaints and
criticism.


No, your problem is your way of communication.

It is a very unfriendly way of communication to request help in the form
patch aiming at immediate removal.


Hopefully everyone has calmed down overnight and we can continue this 
discussion politely?


Yes, Alex's commit message should have spelt out that both:
1) there are doubts anyone is actually using zmodem still (he did this)
2) the source is positively ancient and building it on modern linux is 
getting harder over time (this was implied by being in a series that 
upgraded gettext and fixed other recipes, instead of being spelt out).


So, if zmodem is still a useful feature to have in core, then is anyone 
willing to step up and either:
1) maintain the recipe.  I'd love someone who uses lrzsz to put a fork 
up on github, integrate all of our patches, and start maintaining it. 
Maybe then other distributions who still ship it will join in too.

2) provide an alternative.

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

[OE-core] [PATCH] ltp: Remove acl and at runtime dependency

[Joerg Vehlow]

From: Joerg Vehlow 

Tests that use at and acl tool were removed in release 20190115.
See ltp commit 0fc9b8624bea8acfdb408bf5ff4916b1453e3daa

Signed-off-by: Joerg Vehlow 
---
 meta/recipes-extended/ltp/ltp_20190517.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-extended/ltp/ltp_20190517.bb 
b/meta/recipes-extended/ltp/ltp_20190517.bb
index 47aa9675d8..60f749b4c0 100644
--- a/meta/recipes-extended/ltp/ltp_20190517.bb
+++ b/meta/recipes-extended/ltp/ltp_20190517.bb
@@ -85,8 +85,6 @@ do_install(){
 }
 
 RDEPENDS_${PN} = "\
-acl \
-at \
 attr \
 bash \
 cpio \
-- 
2.20.1

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

Re: [OE-core] How to backport openssl to Sumo

[Mikko.Rapeli]

On Wed, Nov 20, 2019 at 03:53:14PM -0800, Andre McCurdy wrote:
> But anyway, in all cases, the way to debug what's going on isn't to
> try random recipe changes and then rebuild the final image. Instead
> you should build your chosen version of openssl, look in the
> packages-split directory to see which package includes the openssl
> command line tool and then add that package to your image.

Or enable buildhistory, build openssl and/or image(s), cd build/buildhistory
and git grep for the binaries needed to find out which binary package
they belong to.

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

Re: [OE-core] How to backport openssl to Sumo

[Mikko.Rapeli]

On Thu, Nov 21, 2019 at 01:05:55AM +0200, Adrian Bunk wrote:
> On Wed, Nov 20, 2019 at 09:39:51PM +, mikko.rap...@bmw.de wrote:
> >...
> > I could submit these too if someone wants to setup a communit maintenance 
> > branch for sumo.
> 
> I would not consider this appropriate for a stable branch. With such 
> invasive changes it would no longer be reasonably safe for users to 
> follow the branch to receive security updates for other recipes.
> 
> In Ubuntu 18.04 security support for OpenSSL 1.0.2 is provided until at 
> least April 2023. Similar schedules exist for other LTS distributions.
> This provides sources for piggy-backing security support for a few years
> after upstream support ends.

Yes, I agree to this. The reasons for the large intrusive backport are:

 * openssl version 1.1.0 in sumo is no longer supported by upstream
   developers, see https://www.openssl.org/policies/releasestrat.html
   "Version 1.1.0 will be supported until 2019-09-11." but 1.1.1
   is an LTS with support unit 2023-09-11

 * many recipes like openssh in sumo do not support openssl 1.1.x and an
   update is needed to cover the API breakage. The backported pathes
   fixes most of the issues in poky and meta-openembedded and I've been
   able to use the set in multiple projects with different BSP stacks.

So in sumo, openssl 1.0.2 could still be maintainable with Ubuntu etc
help even when upstream openssl.org support has now ended. Same could
apply to openssl 1.1.0 there, but if one suffers and fixes the API
changes, then it is maybe better for users to jump directly to the next
openssl 1.1.1x LTS version. The patches I mentioned achieve this,
but I agree they are intrucive and not following stable policies.

In my case, openssl 1.1.x transition is one of the major blockers
for doing more yocto updates and running closer to master. The backport
has helped there and a following jump to zeus was really straight
forward (ignoring lots of issues in BSP layers but that's life).

Then a note on openssl 1.1.x impact to various BSP layers, some scripting and
bbclasses related to signing etc may need to be updated but also
those changes are simple. I wish there was more open source community
approach so share changes like these among users of various BSPs.

Cheers,

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