date:20201130

Re: [OE-core] [PATCHv2 3/4] bitbake.conf: Canonicalize paths in PSEUDO_IGNORE_PATHS

2020-11-30 Thread Richard Purdie

On Mon, 2020-11-30 at 17:44 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Richard Purdie
> > Sent: den 27 november 2020 00:42
> > To: Peter Kjellerstedt ; openembedded-
> > c...@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCHv2 3/4] bitbake.conf: Canonicalize paths in
> > PSEUDO_IGNORE_PATHS
> > 
> > On Thu, 2020-11-26 at 20:38 +, Peter Kjellerstedt wrote:
> > > > -Original Message-
> > > > From: Richard Purdie 
> > > > Sent: den 26 november 2020 15:47
> > > > To: Peter Kjellerstedt ; openembedded-
> > > > c...@lists.openembedded.org
> > > > Subject: Re: [OE-core] [PATCHv2 3/4] bitbake.conf: Canonicalize
> > > > paths in
> > > > PSEUDO_IGNORE_PATHS
> > > > 
> > > > On Wed, 2020-11-25 at 14:48 +0100, Peter Kjellerstedt wrote:
> > > > > Introduce PSEUDO_IGNORE_REAL_PATHS and make it contain the
> > > > canonicalized
> > > > > paths from PSEUDO_IGNORE_PATHS, obtained by passing the latter to
> > > > > oe.path.to_real_paths(). This is needed since pseudo's
> > > > > pseudo_client_ignore_path_chroot() will compare the ignored paths
> > > > > to
> > > > > paths that have been canonicalized.
> > > > > 
> > > > > Signed-off-by: Peter Kjellerstedt 
> > > > > ---
> > > > >  meta/conf/bitbake.conf | 8 +---
> > > > >  1 file changed, 5 insertions(+), 3 deletions(-)
> > > > 
> > > > This looks like a good way to fix this, except I have a strong
> > > > dislike
> > > > of "REAL" variables.
> > > 
> > > Well, I named it PSEUDO_IGNORE_REAL_PATHS to match
> > > os.path.realpath().
> > > I can name it, e.g., PSEUDO_IGNORE_CANONICAL_PATHS if you prefer
> > > that?
> > 
> > My point was less about the name and more that I'd prefer not to have
> > an indirect variable which isn't useful.
> > 
> > > > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > > > > index 9742fe4fe2..4862095a1b 100644
> > > > > --- a/meta/conf/bitbake.conf
> > > > > +++ b/meta/conf/bitbake.conf
> > > > > @@ -685,15 +685,16 @@ SRC_URI = ""
> > > > >  PSEUDO_LOCALSTATEDIR ?= "${WORKDIR}/pseudo/"
> > > > >  PSEUDO_PASSWD ?= "${STAGING_DIR_TARGET}:${PSEUDO_SYSROOT}"
> > > > >  PSEUDO_SYSROOT = "${COMPONENTS_DIR}/${BUILD_ARCH}/pseudo-native"
> > > > > +PSEUDO_IGNORE_REAL_PATHS = "${@','.join(os.path.realpath(path) for
> > > > path in (d.getVar('PSEUDO_IGNORE_PATHS') or '').split(','))}"
> > > > >  PSEUDO_IGNORE_PATHS =
> > "/usr/,/etc/,/lib,/dev/,${T},${WORKDIR}/recipe-
> > > > sysroot,${SSTATE_DIR},${STAMPS_DIR},${WORKDIR}/pkgdata-
> > > > sysroot,${TMPDIR}/sstate-control,${DEPLOY_DIR},${WORKDIR}/deploy-
> > > > ,${TMPDIR}/buildstats,${WORKDIR}/sstate-build-
> > package_,${WORKDIR}/sstate-
> > > > install-package_,${WORKDIR}/sstate-build-
> > > > image_complete,${TMPDIR}/sysroots-
> > > > 
> > components,${BUILDHISTORY_DIR},${TMPDIR}/pkgdata,${TOPDIR}/cache,${COREBA
> > > > SE}/scripts,${@','.join(d.getVar('BBLAYERS').split())},${CCACHE_DIR}"
> > > > >  export PSEUDO_DISABLED = "1"
> > > > >  #export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"
> > > > >  #export PSEUDO_BINDIR = "${STAGING_DIR_NATIVE}${bindir_native}"
> > > > >  #export PSEUDO_LIBDIR =
> > > > "${STAGING_DIR_NATIVE}$PSEUDOBINDIR/../lib/pseudo/lib
> > > > > -FAKEROOTBASEENV = "PSEUDO_BINDIR=${PSEUDO_SYSROOT}${bindir_native}
> > > > PSEUDO_LIBDIR=${PSEUDO_SYSROOT}${prefix_native}/lib/pseudo/lib
> > > > PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
> > > > PSEUDO_IGNORE_PATHS=${PSEUDO_IGNORE_PATHS} PSEUDO_DISABLED=1"
> > > > > +FAKEROOTBASEENV = "PSEUDO_BINDIR=${PSEUDO_SYSROOT}${bindir_native}
> > > > PSEUDO_LIBDIR=${PSEUDO_SYSROOT}${prefix_native}/lib/pseudo/lib
> > > > PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
> > > > PSEUDO_IGNORE_PATHS=${PSEUDO_IGNORE_REAL_PATHS} PSEUDO_DISABLED=1"
> > > > >  FAKEROOTCMD = "${PSEUDO_SYSROOT}${bindir_native}/pseudo"
> > > > > -FAKEROOTENV = "PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
> > > > PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR}
> > > > PSEUDO_PASSWD=${PSEUDO_PASSWD} PSEUDO_NOSYMLINKEXP=1
> > > > PSEUDO_IGNORE_PATHS=${PSEUDO_IGNORE_PATHS} PSEUDO_DISABLED=0"
> > > > > +FAKEROOTENV = "PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
> > > > PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR}
> > > > PSEUDO_PASSWD=${PSEUDO_PASSWD} PSEUDO_NOSYMLINKEXP=1
> > > > PSEUDO_IGNORE_PATHS=${PSEUDO_IGNORE_REAL_PATHS} PSEUDO_DISABLED=0"
> > > > 
> > > > I'm wondering if we create a function in lib/oe/utils.py and then use
> > > > something like:
> > > > 
> > > > PSEUDO_IGNORE_PATHS=${@oe.utils.realpath("PSEUDO_IGNORE_REAL_PATHS")}
> > > 
> > > There already is an oe.path.realpath(). However, I am not sure when
> > > it is expected to be used instead of os.path.realpath().
> > 
> > That is a bad choice of name now I look at it! I was thinking more
> > about the use of a function.
> > 
> > > I initially created an oe.path.realpaths(d, var, separator=','), but
> > > after I had rewritten it a couple

[OE-core] [meta-oe][PATCH v2] procps: split into binary subpackages

2020-11-30 Thread Sinan Kaya

This change allows you to pull individual binaries into the
target without including the entire suite.

Signed-off-by: Sinan Kaya 
---
 meta/recipes-extended/procps/procps_3.3.16.bb | 51 +--
 1 file changed, 48 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-extended/procps/procps_3.3.16.bb 
b/meta/recipes-extended/procps/procps_3.3.16.bb
index 2810ebd285a..1b62ae33f5c 100644
--- a/meta/recipes-extended/procps/procps_3.3.16.bb
+++ b/meta/recipes-extended/procps/procps_3.3.16.bb
@@ -50,15 +50,13 @@ do_install_append () {
 
 CONFFILES_${PN} = "${sysconfdir}/sysctl.conf"
 
-bindir_progs = "free pkill pmap pgrep pwdx skill snice top uptime w"
+bindir_progs = "free pkill pmap pgrep pwdx skill slabtop snice tload top 
uptime vmstat w"
 base_bindir_progs += "kill pidof ps watch"
 base_sbindir_progs += "sysctl"
 
 ALTERNATIVE_PRIORITY = "200"
 ALTERNATIVE_PRIORITY[pidof] = "150"
 
-ALTERNATIVE_${PN} = "${bindir_progs} ${base_bindir_progs} 
${base_sbindir_progs}"
-
 ALTERNATIVE_${PN}-doc = "kill.1 uptime.1"
 ALTERNATIVE_LINK_NAME[kill.1] = "${mandir}/man1/kill.1"
 ALTERNATIVE_LINK_NAME[uptime.1] = "${mandir}/man1/uptime.1"
@@ -69,8 +67,55 @@ python __anonymous() {
 
 for prog in d.getVar('base_sbindir_progs').split():
 d.setVarFlag('ALTERNATIVE_LINK_NAME', prog, '%s/%s' % 
(d.getVar('base_sbindir'), prog))
+
+for prog in d.getVar('bindir_progs').split():
+d.setVarFlag('ALTERNATIVE_LINK_NAME', prog, '%s/%s' % 
(d.getVar('bindir'), prog))
 }
 
 # 'ps' isn't suitable for use as a security tool so whitelist this CVE.
 # https://bugzilla.redhat.com/show_bug.cgi?id=1575473#c3
 CVE_CHECK_WHITELIST += "CVE-2018-1121"
+
+python __anonymous () {
+packages = []
+for prog in d.getVar('bindir_progs').split():
+pkg = "procps-%s" % prog.replace("_", "-")
+packages.append(pkg)
+d.setVar("RDEPENDS_%s" % pkg, "procps-lib")
+d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${bindir}/%s*" % prog)
+for prog in d.getVar('base_sbindir_progs').split():
+pkg = "procps-%s" % prog.replace("_", "-")
+packages.append(pkg)
+d.setVar("RDEPENDS_%s" % pkg, "procps-lib")
+d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${base_sbindir}/%s*" % prog)
+for prog in d.getVar('base_bindir_progs').split():
+pkg = "procps-%s" % prog.replace("_", "-")
+packages.append(pkg)
+d.setVar("RDEPENDS_%s" % pkg, "procps-lib")
+d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${base_bindir}/%s*" % prog)
+pkg = "procps-man"
+packages.append(pkg)
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${mandir}/*")
+pkg = "procps-lib"
+packages.append(pkg)
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${libdir}/*")
+pkg = "procps-sysctl"
+d.appendVar("FILES_%s" % pkg, " ${sysconfdir}/sysctl.conf")
+
+d.setVar("PROCPS_PACKAGES", " ".join(packages))
+}
+# "procps" is a metapackage which pulls in all procps binaries
+PACKAGES += "${PROCPS_PACKAGES}"
+PROVIDES += "${PROCPS_PACKAGES}"
+FILES_${PN} = ""
+ALLOW_EMPTY_${PN} = "1"
+RRECOMMENDS_${PN} += "${PROCPS_PACKAGES}"
+
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145109): 
https://lists.openembedded.org/g/openembedded-core/message/145109
Mute This Topic: https://lists.openembedded.org/mt/78625996/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [meta-oe][PATCH] procps: split into binary subpackages

2020-11-30 Thread Sinan Kaya

This change allows you to pull individual binaries into the
target without including the entire suite.

Signed-off-by: Sinan Kaya 
---
 meta/recipes-extended/procps/procps_3.3.16.bb | 51 +--
 1 file changed, 48 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-extended/procps/procps_3.3.16.bb 
b/meta/recipes-extended/procps/procps_3.3.16.bb
index 2810ebd285a..540c5cd8b0d 100644
--- a/meta/recipes-extended/procps/procps_3.3.16.bb
+++ b/meta/recipes-extended/procps/procps_3.3.16.bb
@@ -50,15 +50,13 @@ do_install_append () {
 
 CONFFILES_${PN} = "${sysconfdir}/sysctl.conf"
 
-bindir_progs = "free pkill pmap pgrep pwdx skill snice top uptime w"
+bindir_progs = "free pkill pmap pgrep pwdx skill slabtop snice tload top 
uptime vmstat w"
 base_bindir_progs += "kill pidof ps watch"
 base_sbindir_progs += "sysctl"
 
 ALTERNATIVE_PRIORITY = "200"
 ALTERNATIVE_PRIORITY[pidof] = "150"
 
-ALTERNATIVE_${PN} = "${bindir_progs} ${base_bindir_progs} 
${base_sbindir_progs}"
-
 ALTERNATIVE_${PN}-doc = "kill.1 uptime.1"
 ALTERNATIVE_LINK_NAME[kill.1] = "${mandir}/man1/kill.1"
 ALTERNATIVE_LINK_NAME[uptime.1] = "${mandir}/man1/uptime.1"
@@ -74,3 +72,50 @@ python __anonymous() {
 # 'ps' isn't suitable for use as a security tool so whitelist this CVE.
 # https://bugzilla.redhat.com/show_bug.cgi?id=1575473#c3
 CVE_CHECK_WHITELIST += "CVE-2018-1121"
+
+python __anonymous () {
+for prog in d.getVar('bindir_progs').split():
+d.setVarFlag('ALTERNATIVE_LINK_NAME', prog, '%s/%s' % 
(d.getVar('bindir'), prog))
+
+packages = []
+for prog in d.getVar('bindir_progs').split():
+pkg = "procps-%s" % prog.replace("_", "-")
+packages.append(pkg)
+d.setVar("RDEPENDS_%s" % pkg, "procps-lib")
+d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${bindir}/%s*" % prog)
+for prog in d.getVar('base_sbindir_progs').split():
+pkg = "procps-%s" % prog.replace("_", "-")
+packages.append(pkg)
+d.setVar("RDEPENDS_%s" % pkg, "procps-lib")
+d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${base_sbindir}/%s*" % prog)
+for prog in d.getVar('base_bindir_progs').split():
+pkg = "procps-%s" % prog.replace("_", "-")
+packages.append(pkg)
+d.setVar("RDEPENDS_%s" % pkg, "procps-lib")
+d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${base_bindir}/%s*" % prog)
+pkg = "procps-man"
+packages.append(pkg)
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${mandir}/*")
+pkg = "procps-lib"
+packages.append(pkg)
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${libdir}/*")
+pkg = "procps-sysctl"
+d.appendVar("FILES_%s" % pkg, " ${sysconfdir}/sysctl.conf")
+
+d.setVar("PROCPS_PACKAGES", " ".join(packages))
+}
+# "procps" is a metapackage which pulls in all procps binaries
+PACKAGES += "${PROCPS_PACKAGES}"
+PROVIDES += "${PROCPS_PACKAGES}"
+FILES_${PN} = ""
+ALLOW_EMPTY_${PN} = "1"
+RRECOMMENDS_${PN} += "${PROCPS_PACKAGES}"
+
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145108): 
https://lists.openembedded.org/g/openembedded-core/message/145108
Mute This Topic: https://lists.openembedded.org/mt/78625972/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [meta-oe][PATCH v3] net-tools: split into binary packages

2020-11-30 Thread Sinan Kaya

Support per binary package to not bloat the system with unneeded
tools.

Signed-off-by: Sinan Kaya 
---
 .../net-tools/net-tools_1.60-20181103.bb  | 29 ++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-20181103.bb 
b/meta/recipes-extended/net-tools/net-tools_1.60-20181103.bb
index e97731073e8..63a3ccbe516 100644
--- a/meta/recipes-extended/net-tools/net-tools_1.60-20181103.bb
+++ b/meta/recipes-extended/net-tools/net-tools_1.60-20181103.bb
@@ -93,7 +93,7 @@ base_bindir_progs  = "ifconfig netstat route \
 ${@bb.utils.contains('PACKAGECONFIG', 'hostname', 'dnsdomainname 
domainname hostname nisdomainname ypdomainname', '', d)} \
 "
 
-ALTERNATIVE_${PN} = "${base_sbindir_progs} ${base_bindir_progs}"
+ALTERNATIVE_${PN} = ""
 ALTERNATIVE_${PN}-doc += "${@bb.utils.contains('PACKAGECONFIG', 'hostname', 
'hostname.1 dnsdomainname.1', '', d)}"
 ALTERNATIVE_LINK_NAME[hostname.1] = "${mandir}/man1/hostname.1"
 ALTERNATIVE_LINK_NAME[dnsdomainname.1] = "${mandir}/man1/dnsdomainname.1"
@@ -107,4 +107,31 @@ python __anonymous() {
 }
 ALTERNATIVE_PRIORITY = "100"
 
+python __anonymous () {
+packages = []
+for prog in d.getVar('base_sbindir_progs').split():
+pkg = "net-tools-%s" % prog.replace("_", "-")
+packages.append(pkg)
+d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${base_sbindir}/%s*" % prog)
+for prog in d.getVar('base_bindir_progs').split():
+pkg = "net-tools-%s" % prog.replace("_", "-")
+packages.append(pkg)
+d.setVar("ALTERNATIVE_%s" % pkg, prog.replace("_", "-"))
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${base_bindir}/%s*" % prog)
+pkg = "net-tools-man"
+packages.append(pkg)
+if not d.getVar("FILES_%s" % pkg):
+d.setVar("FILES_%s" % pkg, "${mandir}/*")
+d.setVar("NETTOOLS_PACKAGES", " ".join(packages))
+}
+# "net-tools" is a metapackage which pulls in all net-tools binaries
+PACKAGES += "${NETTOOLS_PACKAGES}"
+PROVIDES += "${NETTOOLS_PACKAGES}"
+FILES_${PN} = ""
+ALLOW_EMPTY_${PN} = "1"
+RRECOMMENDS_${PN} += "${NETTOOLS_PACKAGES}"
+
 BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145107): 
https://lists.openembedded.org/g/openembedded-core/message/145107
Mute This Topic: https://lists.openembedded.org/mt/78625904/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/1] classes/kernel*: allow disabling symlink creation

2020-11-30 Thread Martin Jansa

Can we use a separate variable controlling this behavior other than
*_LINK_NAME variables being set to empty?

Then we could easily extend it to stop creating the links also for image
artifacts as well.

On Thu, Nov 26, 2020 at 7:55 PM Paul Eggleton <
bluelightn...@bluelightning.org> wrote:

> On Thursday, 26 November 2020 14:01:47 NZDT Paul Eggleton wrote:
> > From: Paul Eggleton 
> >
> > Allow setting any of the *_LINK_NAME variables to empty string in order
> > to disable creating symlinks. This is particularly useful for situations
> > where symlinks in DEPLOY_DIR_IMAGE will be treated externally as
> > duplicates of the linked files (in which case you would probably set
> > KERNEL_ARTIFACT_LINK_NAME = "" to disable them all at once).
>
> I missed something - v2 incoming.
>
> Cheers
> Paul
>
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145106): 
https://lists.openembedded.org/g/openembedded-core/message/145106
Mute This Topic: https://lists.openembedded.org/mt/78513443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][master][PATCH] qemu: CVE-2020-29129 CVE-2020-29130

2020-11-30 Thread Li Wang

References:
https://nvd.nist.gov/vuln/detail/CVE-2020-29129
https://nvd.nist.gov/vuln/detail/CVE-2020-29130

backport patch from:
https://git.qemu.org/?p=libslirp.git;a=commit;h=2e1dcbc0c2af64fcb17009eaf2ceedd81be2b27f

Signed-off-by: Li Wang 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/CVE-2020-29129-CVE-2020-29130.patch  | 64 +++
 2 files changed, 65 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/CVE-2020-29129-CVE-2020-29130.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 11be545cb5..bbe2a39755 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -33,6 +33,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://usb-fix-setup_len-init.patch \

file://0001-target-mips-Increase-number-of-TLB-entries-on-the-34.patch \
file://CVE-2020-24352.patch \
+   file://CVE-2020-29129-CVE-2020-29130.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git 
a/meta/recipes-devtools/qemu/qemu/CVE-2020-29129-CVE-2020-29130.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2020-29129-CVE-2020-29130.patch
new file mode 100644
index 00..e5829f6dad
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-29129-CVE-2020-29130.patch
@@ -0,0 +1,64 @@
+From 2e1dcbc0c2af64fcb17009eaf2ceedd81be2b27f Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Thu, 26 Nov 2020 19:27:06 +0530
+Subject: [PATCH] slirp: check pkt_len before reading protocol header
+MIME-Version: 1.0
+Content-Type: text/plain; charset=utf8
+Content-Transfer-Encoding: 8bit
+
+While processing ARP/NCSI packets in 'arp_input' or 'ncsi_input'
+routines, ensure that pkt_len is large enough to accommodate the
+respective protocol headers, lest it should do an OOB access.
+Add check to avoid it.
+
+CVE-2020-29129 CVE-2020-29130
+  QEMU: slirp: out-of-bounds access while processing ARP/NCSI packets
+ -> https://www.openwall.com/lists/oss-security/2020/11/27/1
+
+Reported-by: Qiuhao Li 
+Signed-off-by: Prasad J Pandit 
+Message-Id: <20201126135706.273950-1-ppan...@redhat.com>
+Reviewed-by: Marc-AndrÃ Lureau 
+
+Upstream-Status: Backport
+CVE: CVE-2020-29129 CVE-2020-29130
+[https://git.qemu.org/?p=libslirp.git;a=commit;h=2e1dcbc0c2af64fcb17009eaf2ceedd81be2b27f]
+Signed-off-by: Li Wang 
+---
+ slirp/src/ncsi.c  | 4 
+ slirp/src/slirp.c | 4 
+ 2 files changed, 8 insertions(+)
+
+diff --git a/slirp/src/ncsi.c b/slirp/src/ncsi.c
+index 3c1dfef..75dcc08 100644
+--- a/slirp/src/ncsi.c
 b/slirp/src/ncsi.c
+@@ -148,6 +148,10 @@ void ncsi_input(Slirp *slirp, const uint8_t *pkt, int 
pkt_len)
+ uint32_t checksum;
+ uint32_t *pchecksum;
+ 
++if (pkt_len < ETH_HLEN + sizeof(struct ncsi_pkt_hdr)) {
++return; /* packet too short */
++}
++
+ memset(ncsi_reply, 0, sizeof(ncsi_reply));
+ 
+ memset(reh->h_dest, 0xff, ETH_ALEN);
+diff --git a/slirp/src/slirp.c b/slirp/src/slirp.c
+index dba7c98..9be58e2 100644
+--- a/slirp/src/slirp.c
 b/slirp/src/slirp.c
+@@ -756,6 +756,10 @@ static void arp_input(Slirp *slirp, const uint8_t *pkt, 
int pkt_len)
+ return;
+ }
+ 
++if (pkt_len < ETH_HLEN + sizeof(struct slirp_arphdr)) {
++return; /* packet too short */
++}
++
+ ar_op = ntohs(ah->ar_op);
+ switch (ar_op) {
+ case ARPOP_REQUEST:
+-- 
+2.17.1
+
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145105): 
https://lists.openembedded.org/g/openembedded-core/message/145105
Mute This Topic: https://lists.openembedded.org/mt/78624759/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)

2020-11-30 Thread Stephen Jolley

All,

 

Just a reminder we will hold the monthly Yocto Project Technical Meeting at
8am PST tomorrow. (12/1)  

 

Yocto Project Technical Team Meeting: We encourage people attending the
meeting to logon and announce themselves on the Yocto Project IRC chancel
during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto

 

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

 

WhenMonthly from 8am to 9am on the first Tuesday Pacific Time

Where   Zoom Meeting:
https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09

 

We are tracking the minutes at:
https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9d
DH4/edit?pli=1 Please request access if you want to assist in editing them.
The world should have view access. 

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145104): 
https://lists.openembedded.org/g/openembedded-core/message/145104
Mute This Topic: https://lists.openembedded.org/mt/78624421/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2020-11-30 Thread Stephen Jolley

All,

 

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

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145103): 
https://lists.openembedded.org/g/openembedded-core/message/145103
Mute This Topic: https://lists.openembedded.org/mt/78624079/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCHv2 1/4] pseudo: Simplify pseudo_client_ignore_path_chroot()

2020-11-30 Thread Peter Kjellerstedt

> -Original Message-
> From: Richard Purdie 
> Sent: den 30 november 2020 12:47
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCHv2 1/4] pseudo: Simplify
> pseudo_client_ignore_path_chroot()
> 
> Hi Peter,
> 
> On Wed, 2020-11-25 at 14:48 +0100, Peter Kjellerstedt wrote:
> > This also plugs a memory leak in pseudo_client_ignore_path_chroot().
> >
> > Signed-off-by: Peter Kjellerstedt 
> 
> I make no claim to understand what happened but I tried patches 1 and 2
> in a build over the weekend and with the first two present:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1602
> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1584
> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1586
> https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/1610
> 
> I then removed this one leaving only patch 2 and the build was fine.
> 
> So there is something odd in this patch but I've not looked into what
> or why only selftest is affected.
> 
> Cheers,
> 
> Richard

I believe I have found the problem. I had missed the edge case where 
two commas are specified immediately after each other, or there is a
leading/trailing comma. This would effectively cause pseudo to ignore 
all paths. Thankfully the fix is trivial.

I have verified that I could repeat the oe-selftest problems for the 
wic.Wic2 tests, and that they are back to working with my updated 
code.

I will wait with sending an updated patch series until I have a 
response regarding how you want me to handle the third patch in 
the series (see my other mail from earlier today).

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145102): 
https://lists.openembedded.org/g/openembedded-core/message/145102
Mute This Topic: https://lists.openembedded.org/mt/78499442/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/2] linux-firmware: upgrade 20201022 -> 20201118

2020-11-30 Thread Dmitry Baryshkov

From: Dmitry Baryshkov 

License-Update: firmware versions/filenames
Signed-off-by: Dmitry Baryshkov 
---
 ...{linux-firmware_20201022.bb => linux-firmware_20201118.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-kernel/linux-firmware/{linux-firmware_20201022.bb => 
linux-firmware_20201118.bb} (99%)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20201022.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20201118.bb
similarity index 99%
rename from meta/recipes-kernel/linux-firmware/linux-firmware_20201022.bb
rename to meta/recipes-kernel/linux-firmware/linux-firmware_20201118.bb
index 93b9d5308aa1..5de7157f3a84 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20201022.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20201118.bb
@@ -126,7 +126,7 @@ LIC_FILES_CHKSUM = 
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
 file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 
\
 file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 
\
 
file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \
-file://WHENCE;md5=daf28db5d6353de0a886f08106cffa22 \
+file://WHENCE;md5=ef221e03fc58f4d34a132b801dfa1d68 \
 "
 
 # These are not common licenses, set NO_GENERIC_LICENSE for them
@@ -198,7 +198,7 @@ PE = "1"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/firmware/${BPN}-${PV}.tar.xz"
 
-SRC_URI[sha256sum] = 
"bf586e0beb4c65f22bf0a79811f259aa0a5a7cc9f70eebecb260525b6914cef7"
+SRC_URI[sha256sum] = 
"863d5a31da725b856a917280d1e3014929b3bc3d4e6e5faecf530c13afb7e2b9"
 
 inherit allarch
 
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145100): 
https://lists.openembedded.org/g/openembedded-core/message/145100
Mute This Topic: https://lists.openembedded.org/mt/78622950/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] linux-firmware: package ath11k firmware

2020-11-30 Thread Dmitry Baryshkov

From: Dmitry Baryshkov 

Package firmware for new generation of Atheros WiFi cards.

Signed-off-by: Dmitry Baryshkov 
---
 .../linux-firmware/linux-firmware_20201118.bb  | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20201118.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20201118.bb
index 5de7157f3a84..baac26c51053 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20201118.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20201118.bb
@@ -261,7 +261,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-bcm43xx-hdr \
  ${PN}-atheros-license ${PN}-ar9170 ${PN}-ath6k ${PN}-ath9k \
  ${PN}-gplv2-license ${PN}-carl9170 \
- ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k 
${PN}-qca \
+ ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k 
${PN}-ath11k ${PN}-qca \
  \
  ${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d \
  \
@@ -356,12 +356,17 @@ FILES_${PN}-ath10k = " \
   ${nonarch_base_libdir}/firmware/ath10k \
 "
 
+FILES_${PN}-ath11k = " \
+  ${nonarch_base_libdir}/firmware/ath11k \
+"
+
 FILES_${PN}-qca = " \
   ${nonarch_base_libdir}/firmware/qca \
 "
 
 RDEPENDS_${PN}-ar3k += "${PN}-ar3k-license"
 RDEPENDS_${PN}-ath10k += "${PN}-ath10k-license"
+RDEPENDS_${PN}-ath11k += "${PN}-ath10k-license"
 RDEPENDS_${PN}-qca += "${PN}-ath10k-license"
 
 # For ralink
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145101): 
https://lists.openembedded.org/g/openembedded-core/message/145101
Mute This Topic: https://lists.openembedded.org/mt/78622951/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-Core][master][gatesgarth][PATCH] populate_sdk_ext: use CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg

2020-11-30 Thread Chandana kalluri

The current implementation will always pick an existing templateconf.cfg if
present else it will use the one from OE.  A user might not always want to pick
an existing tempalteconf.cfg even if its present.  Introduce
CUSTOM_TEMPLATECONF variable to provide an option for the user to specify if he
wants to use an existing custom templateconf.cfg or not

If CUSTOM_TEMPLATECONF=='1' then enable custom templateconf.cfg. By default
CUSTOM_TEMPLATECONF is set to '0'

Signed-off-by: Sai Hari Chandana Kalluri 
---
 meta/classes/populate_sdk_ext.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 6f35b61..d1f61d5 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -24,6 +24,7 @@ SDK_INCLUDE_NATIVESDK ?= "0"
 SDK_INCLUDE_BUILDTOOLS ?= '1'
 
 SDK_RECRDEP_TASKS ?= ""
+CUSTOM_TEMPLATECONF ?= "0"
 
 SDK_LOCAL_CONF_WHITELIST ?= ""
 SDK_LOCAL_CONF_BLACKLIST ?= "CONF_VERSION \
@@ -199,6 +200,9 @@ python copy_buildsystem () {
 buildsystem = oe.copy_buildsystem.BuildSystem('extensible SDK', d)
 baseoutpath = d.getVar('SDK_OUTPUT') + '/' + d.getVar('SDKPATH')
 
+#check if custome templateconf path is set
+use_custom_templateconf = d.getVar('CUSTOM_TEMPLATECONF')
+
 # Determine if we're building a derivative extensible SDK (from devtool 
build-sdk)
 derivative = (d.getVar('SDK_DERIVATIVE') or '') == '1'
 if derivative:
@@ -390,7 +394,7 @@ python copy_buildsystem () {
 shutil.copyfile(builddir + '/cache/bb_unihashes.dat', baseoutpath + 
'/cache/bb_unihashes.dat')
 
 # Use templateconf.cfg file from builddir if exists
-if os.path.exists(builddir + '/conf/templateconf.cfg'):
+if os.path.exists(builddir + '/conf/templateconf.cfg') and 
use_custom_templateconf == '1':
 shutil.copyfile(builddir + '/conf/templateconf.cfg', baseoutpath + 
'/conf/templateconf.cfg')
 else:
 # Write a templateconf.cfg
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145099): 
https://lists.openembedded.org/g/openembedded-core/message/145099
Mute This Topic: https://lists.openembedded.org/mt/78619994/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 00/18] Move python3-pytest to oe-core

2020-11-30 Thread Richard Purdie

On Fri, 2020-11-27 at 20:24 -0800, Tim Orling wrote:
> From: Tim Orling 
> 
> We are increasingly needing pytest in oe-core, so it is time to move it
> from meta-python.
> 
> This series first imports the recipes -- as-is -- from meta-python.
> Second, the maintainers.inc is updated to add myself as maintainer for all
> the new recipes.
> Third, the two recipes that have stable updates are updated to their
> latest releases.
> Finally, a fix caught during ptest runs is added for RDEPENDS for
> pytest.
> 
> This was built on 'nodistro' with only openembedded-core and tested on 
> qemux86-64. All the new recipes that have ptests pass all tests.

That series was an easier one to test and merge :)

Thanks Tim!

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145098): 
https://lists.openembedded.org/g/openembedded-core/message/145098
Mute This Topic: https://lists.openembedded.org/mt/78561666/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 2/2] connman: set service to conflict with systemd-networkd

2020-11-30 Thread Jack Mitchell

On 02/11/2020 09:20, Yi Zhao wrote:
> Do not run systemd-networkd and connman simultaneously. These two
> network managers may conflict with each other.
> 
> Signed-off-by: Yi Zhao 
> ---
>  ...stop-systemd-networkd-when-using-con.patch | 29 +++
>  .../connman/connman_1.38.bb   |  1 +
>  2 files changed, 30 insertions(+)
>  create mode 100644 
> meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
> 
> diff --git 
> a/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
>  
> b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
> new file mode 100644
> index 00..dd012750a4
> --- /dev/null
> +++ 
> b/meta/recipes-connectivity/connman/connman/0001-connman.service-stop-systemd-networkd-when-using-con.patch
> @@ -0,0 +1,29 @@
> +From 9fea099d0a3ece37d80ad70d32ebb8a93f8f3280 Mon Sep 17 00:00:00 2001
> +From: Yi Zhao 
> +Date: Fri, 30 Oct 2020 13:48:45 +0800
> +Subject: [PATCH] connman.service: stop systemd-networkd when using connman
> +
> +Stop systemd-networkd service when we use connman as network manager.
> +
> +Upstream-Status: Inappropriate [configuration]
> +
> +Signed-off-by: Yi Zhao 
> +---
> + src/connman.service.in | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/src/connman.service.in b/src/connman.service.in
> +index 79e75d6..014eafe 100644
> +--- a/src/connman.service.in
>  b/src/connman.service.in
> +@@ -6,6 +6,7 @@ RequiresMountsFor=@localstatedir@/lib/connman
> + After=dbus.service network-pre.target systemd-sysusers.service
> + Before=network.target multi-user.target shutdown.target
> + Wants=network.target
> ++Conflicts=systemd-networkd.service systemd-networkd.socket
> + Conflicts=systemd-resolved.service
> + 
> + [Service]
> +-- 
> +2.17.1
> +
> diff --git a/meta/recipes-connectivity/connman/connman_1.38.bb 
> b/meta/recipes-connectivity/connman/connman_1.38.bb
> index 027c41e9af..45c2934dec 100644
> --- a/meta/recipes-connectivity/connman/connman_1.38.bb
> +++ b/meta/recipes-connectivity/connman/connman_1.38.bb
> @@ -3,6 +3,7 @@ require connman.inc
>  SRC_URI = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
> 
> file://0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch \
> 
> file://0001-connman.service-stop-systemd-resolved-when-we-use-co.patch \
> +   
> file://0001-connman.service-stop-systemd-networkd-when-using-con.patch \
> file://connman \
> file://no-version-scripts.patch \
> "
> 

Hi Yi,

This breaks our usecase where we have been using connman and
systemd-networkd in tandem for a long time. IMO this should be reverted
as if the two applications are conflicting then the correct fix is that
they should be configured so that they don't both try to configure the
same interfaces. As systemd-networkd doesn't ship with any rules by
default it shouldn't be doing anything to interfere?

With this patch I can no-longer run both services as it's a hard
conflict with no option to either revert locally, or bbappend this patch
out.

Regards,
Jack.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145097): 
https://lists.openembedded.org/g/openembedded-core/message/145097
Mute This Topic: https://lists.openembedded.org/mt/77977444/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCHv2 3/4] bitbake.conf: Canonicalize paths in PSEUDO_IGNORE_PATHS

2020-11-30 Thread Peter Kjellerstedt

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 27 november 2020 00:42
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCHv2 3/4] bitbake.conf: Canonicalize paths in
> PSEUDO_IGNORE_PATHS
> 
> On Thu, 2020-11-26 at 20:38 +, Peter Kjellerstedt wrote:
> > > -Original Message-
> > > From: Richard Purdie 
> > > Sent: den 26 november 2020 15:47
> > > To: Peter Kjellerstedt ; openembedded-
> > > c...@lists.openembedded.org
> > > Subject: Re: [OE-core] [PATCHv2 3/4] bitbake.conf: Canonicalize
> > > paths in
> > > PSEUDO_IGNORE_PATHS
> > >
> > > On Wed, 2020-11-25 at 14:48 +0100, Peter Kjellerstedt wrote:
> > > > Introduce PSEUDO_IGNORE_REAL_PATHS and make it contain the
> > > canonicalized
> > > > paths from PSEUDO_IGNORE_PATHS, obtained by passing the latter to
> > > > oe.path.to_real_paths(). This is needed since pseudo's
> > > > pseudo_client_ignore_path_chroot() will compare the ignored paths
> > > > to
> > > > paths that have been canonicalized.
> > > >
> > > > Signed-off-by: Peter Kjellerstedt 
> > > > ---
> > > >  meta/conf/bitbake.conf | 8 +---
> > > >  1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > This looks like a good way to fix this, except I have a strong
> > > dislike
> > > of "REAL" variables.
> >
> > Well, I named it PSEUDO_IGNORE_REAL_PATHS to match
> > os.path.realpath().
> > I can name it, e.g., PSEUDO_IGNORE_CANONICAL_PATHS if you prefer
> > that?
> 
> My point was less about the name and more that I'd prefer not to have
> an indirect variable which isn't useful.
> 
> > > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > > > index 9742fe4fe2..4862095a1b 100644
> > > > --- a/meta/conf/bitbake.conf
> > > > +++ b/meta/conf/bitbake.conf
> > > > @@ -685,15 +685,16 @@ SRC_URI = ""
> > > >  PSEUDO_LOCALSTATEDIR ?= "${WORKDIR}/pseudo/"
> > > >  PSEUDO_PASSWD ?= "${STAGING_DIR_TARGET}:${PSEUDO_SYSROOT}"
> > > >  PSEUDO_SYSROOT = "${COMPONENTS_DIR}/${BUILD_ARCH}/pseudo-native"
> > > > +PSEUDO_IGNORE_REAL_PATHS = "${@','.join(os.path.realpath(path) for
> > > path in (d.getVar('PSEUDO_IGNORE_PATHS') or '').split(','))}"
> > > >  PSEUDO_IGNORE_PATHS =
> "/usr/,/etc/,/lib,/dev/,${T},${WORKDIR}/recipe-
> > > sysroot,${SSTATE_DIR},${STAMPS_DIR},${WORKDIR}/pkgdata-
> > > sysroot,${TMPDIR}/sstate-control,${DEPLOY_DIR},${WORKDIR}/deploy-
> > > ,${TMPDIR}/buildstats,${WORKDIR}/sstate-build-
> package_,${WORKDIR}/sstate-
> > > install-package_,${WORKDIR}/sstate-build-
> > > image_complete,${TMPDIR}/sysroots-
> > >
> components,${BUILDHISTORY_DIR},${TMPDIR}/pkgdata,${TOPDIR}/cache,${COREBA
> > > SE}/scripts,${@','.join(d.getVar('BBLAYERS').split())},${CCACHE_DIR}"
> > > >  export PSEUDO_DISABLED = "1"
> > > >  #export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"
> > > >  #export PSEUDO_BINDIR = "${STAGING_DIR_NATIVE}${bindir_native}"
> > > >  #export PSEUDO_LIBDIR =
> > > "${STAGING_DIR_NATIVE}$PSEUDOBINDIR/../lib/pseudo/lib
> > > > -FAKEROOTBASEENV = "PSEUDO_BINDIR=${PSEUDO_SYSROOT}${bindir_native}
> > > PSEUDO_LIBDIR=${PSEUDO_SYSROOT}${prefix_native}/lib/pseudo/lib
> > > PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
> > > PSEUDO_IGNORE_PATHS=${PSEUDO_IGNORE_PATHS} PSEUDO_DISABLED=1"
> > > > +FAKEROOTBASEENV = "PSEUDO_BINDIR=${PSEUDO_SYSROOT}${bindir_native}
> > > PSEUDO_LIBDIR=${PSEUDO_SYSROOT}${prefix_native}/lib/pseudo/lib
> > > PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
> > > PSEUDO_IGNORE_PATHS=${PSEUDO_IGNORE_REAL_PATHS} PSEUDO_DISABLED=1"
> > > >  FAKEROOTCMD = "${PSEUDO_SYSROOT}${bindir_native}/pseudo"
> > > > -FAKEROOTENV = "PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
> > > PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR}
> > > PSEUDO_PASSWD=${PSEUDO_PASSWD} PSEUDO_NOSYMLINKEXP=1
> > > PSEUDO_IGNORE_PATHS=${PSEUDO_IGNORE_PATHS} PSEUDO_DISABLED=0"
> > > > +FAKEROOTENV = "PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
> > > PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR}
> > > PSEUDO_PASSWD=${PSEUDO_PASSWD} PSEUDO_NOSYMLINKEXP=1
> > > PSEUDO_IGNORE_PATHS=${PSEUDO_IGNORE_REAL_PATHS} PSEUDO_DISABLED=0"
> > >
> > > I'm wondering if we create a function in lib/oe/utils.py and then use
> > > something like:
> > >
> > > PSEUDO_IGNORE_PATHS=${@oe.utils.realpath("PSEUDO_IGNORE_REAL_PATHS")}
> >
> > There already is an oe.path.realpath(). However, I am not sure when
> > it is expected to be used instead of os.path.realpath().
> 
> That is a bad choice of name now I look at it! I was thinking more
> about the use of a function.
> 
> > I initially created an oe.path.realpaths(d, var, separator=','), but
> > after I had rewritten it a couple of times I was down to just the
> > single list comprehension and then I felt as I could just as well
> > use it directly since I don't see a great need for a common function
> > to canonicalize a list of paths. But if you prefer that solution, I
> > can restore it.
> 
>

Re: [OE-core] Dunfell CVE reduction fun: December raffle

2020-11-30 Thread Steve Sakoman

I neglected to mention that I post a list of outstanding CVE's to
openembedded-core@lists.openembedded.org every Sunday.  You can browse
that email to select CVEs to work on.

Steve

On Mon, Nov 30, 2020 at 7:12 AM Steve Sakoman via
lists.openembedded.org 
wrote:
>
> We've been making good progress on reducing the number of issues
> reported by the CVE checker.  We went from 202 on August 16 to 59 on
> November 29.
>
> Some of these reductions have come from sending in corrections to the
> CVE database where there were errors in version matching, and others
> have come from backported fixes or whitelisting..  Many thanks to all
> who have helped!
>
> To encourage more folks to contribute to this effort I'm going to be
> holding a raffle during the month of December.  You'll get one entry
> for each CVE fix patch that I merge into dunfell.  And a database
> update that results in a reduction in dunell reported issues will also
> get you an entry.
>
> The prize?  A bag of fresh roasted whole bean coffee from my small
> coffee orchard here on the Big Island of Hawaii.  If the winner isn't
> a coffee drinker I'll try to get some locally grown tea as a
> substitute prize.
>
> The fine print:
>
> 1. Patches and database update requests must be submitted during the
> month of December to receive a raffle entry.
>
> 2. CVE patch submissions should follow the guidelines in the "Patch
> name convention and commit message" section of
> https://wiki.yoctoproject.org/wiki/Security
>
> 3. If the patch also applies to master please send the patch for
> master and note that it should be backported to dunfell/gatesgarth as
> appropriate.  I'll pull this type of patch into dunfell only after it
> hits master.
>
> 4. CVE database update requests should be sent to:
> cpe_diction...@nist.gov  You should note the CVE number and provide
> supporting links for why you think an update is appropriate. When you
> receive a "Thank you for bringing this to our attention. We appreciate
> community input" response please forward a copy to me.  I'll add your
> raffle entry to the pool when the database is updated and the dunfell
> cve count reduced.
>
> 5. To help avoid people working on the same CVE's I'll start a "CVE
> raffle: collision avoidance" thread on this list.  Just do a quick
> reply noting which CVE you plan to work on.  Please don't claim one
> unless you really intend to follow through!
>
> Steve
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145095): 
https://lists.openembedded.org/g/openembedded-core/message/145095
Mute This Topic: https://lists.openembedded.org/mt/78613043/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] CVE raffle: collision avoidance

2020-11-30 Thread Steve Sakoman

Reply to this thread noting which CVE you plan to work on.  Please
don't claim one
unless you really intend to follow through!

Note: there are already outstanding CVE database update requests for
most of the older qemu issues.  Fixes for recent CVE's are fair game
though!

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145094): 
https://lists.openembedded.org/g/openembedded-core/message/145094
Mute This Topic: https://lists.openembedded.org/mt/78613451/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Dunfell CVE reduction fun: December raffle

2020-11-30 Thread Steve Sakoman

We've been making good progress on reducing the number of issues
reported by the CVE checker.  We went from 202 on August 16 to 59 on
November 29.

Some of these reductions have come from sending in corrections to the
CVE database where there were errors in version matching, and others
have come from backported fixes or whitelisting..  Many thanks to all
who have helped!

To encourage more folks to contribute to this effort I'm going to be
holding a raffle during the month of December.  You'll get one entry
for each CVE fix patch that I merge into dunfell.  And a database
update that results in a reduction in dunell reported issues will also
get you an entry.

The prize?  A bag of fresh roasted whole bean coffee from my small
coffee orchard here on the Big Island of Hawaii.  If the winner isn't
a coffee drinker I'll try to get some locally grown tea as a
substitute prize.

The fine print:

1. Patches and database update requests must be submitted during the
month of December to receive a raffle entry.

2. CVE patch submissions should follow the guidelines in the "Patch
name convention and commit message" section of
https://wiki.yoctoproject.org/wiki/Security

3. If the patch also applies to master please send the patch for
master and note that it should be backported to dunfell/gatesgarth as
appropriate.  I'll pull this type of patch into dunfell only after it
hits master.

4. CVE database update requests should be sent to:
cpe_diction...@nist.gov  You should note the CVE number and provide
supporting links for why you think an update is appropriate. When you
receive a "Thank you for bringing this to our attention. We appreciate
community input" response please forward a copy to me.  I'll add your
raffle entry to the pool when the database is updated and the dunfell
cve count reduced.

5. To help avoid people working on the same CVE's I'll start a "CVE
raffle: collision avoidance" thread on this list.  Just do a quick
reply noting which CVE you plan to work on.  Please don't claim one
unless you really intend to follow through!

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145093): 
https://lists.openembedded.org/g/openembedded-core/message/145093
Mute This Topic: https://lists.openembedded.org/mt/78613043/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v5 2/5] python3-numpy: Add ptest

2020-11-30 Thread Khem Raj

On Mon, Nov 30, 2020 at 6:11 AM Ross Burton  wrote:
>
> Why are all the patches from this not squashed into this?  We don't
> need to see the bugs you fixed.

Right.
heh its better to eat the sausage than to see it being made.
Richard did it before pushing to all is set.
>
> Ross
>
> On Sun, 29 Nov 2020 at 07:48, Khem Raj  wrote:
> >
> > Since 1.15, numpy have replaced nose with pytest testing framework
> > it additionally needs hypothesis and sortedcontainers modules
> >
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/recipes-devtools/python-numpy/files/run-ptest | 5 +
> >  meta/recipes-devtools/python-numpy/python3-numpy_1.19.4.bb | 7 +--
> >  2 files changed, 10 insertions(+), 2 deletions(-)
> >  create mode 100644 meta/recipes-devtools/python-numpy/files/run-ptest
> >
> > diff --git a/meta/recipes-devtools/python-numpy/files/run-ptest 
> > b/meta/recipes-devtools/python-numpy/files/run-ptest
> > new file mode 100644
> > index 00..9a1c72aeb1
> > --- /dev/null
> > +++ b/meta/recipes-devtools/python-numpy/files/run-ptest
> > @@ -0,0 +1,5 @@
> > +#!/usr/bin/env python3
> > +
> > +import numpy
> > +numpy.test(label='full', verbose=2)
> > +
> > diff --git a/meta/recipes-devtools/python-numpy/python3-numpy_1.19.4.bb 
> > b/meta/recipes-devtools/python-numpy/python3-numpy_1.19.4.bb
> > index d54f2f6c18..b484e7cddc 100644
> > --- a/meta/recipes-devtools/python-numpy/python3-numpy_1.19.4.bb
> > +++ b/meta/recipes-devtools/python-numpy/python3-numpy_1.19.4.bb
> > @@ -8,6 +8,7 @@ SRCNAME = "numpy"
> >  SRC_URI = 
> > "https://github.com/${SRCNAME}/${SRCNAME}/releases/download/v${PV}/${SRCNAME}-${PV}.tar.gz
> >  \
> > 
> > file://0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch \
> > file://0001-numpy-core-Define-RISCV-32-support.patch \
> > +   file://run-ptest \
> >  "
> >  SRC_URI[sha256sum] = 
> > "fe836a685d6838dbb3f603caef01183ea98e88febf4ce956a2ea484a75378413"
> >
> > @@ -16,7 +17,7 @@ UPSTREAM_CHECK_REGEX = "(?P\d+(\.\d+)+)\.tar"
> >
> >  DEPENDS += "python3-cython-native"
> >
> > -inherit setuptools3
> > +inherit ptest setuptools3
> >
> >  S = "${WORKDIR}/numpy-${PV}"
> >
> > @@ -30,7 +31,6 @@ RDEPENDS_${PN} = "${PYTHON_PN}-unittest \
> >${PYTHON_PN}-pprint \
> >${PYTHON_PN}-pickle \
> >${PYTHON_PN}-shell \
> > -  ${PYTHON_PN}-nose \
> >${PYTHON_PN}-doctest \
> >${PYTHON_PN}-datetime \
> >${PYTHON_PN}-distutils \
> > @@ -39,6 +39,9 @@ RDEPENDS_${PN} = "${PYTHON_PN}-unittest \
> >${PYTHON_PN}-netclient \
> >${PYTHON_PN}-numbers \
> >${PYTHON_PN}-pydoc \
> > +  ${PYTHON_PN}-pytest \
> > +  ${PYTHON_PN}-hypothesis \
> > +  ${PYTHON_PN}-sortedcontainers \
> >${PYTHON_PN}-pkgutil \
> >${PYTHON_PN}-email \
> >${PYTHON_PN}-compression \
> > --
> > 2.29.2
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145092): 
https://lists.openembedded.org/g/openembedded-core/message/145092
Mute This Topic: https://lists.openembedded.org/mt/78581725/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] dbus: move messagebus user to dbus-common package

2020-11-30 Thread Luca Bocassi

From: Luca Boccassi 

dbus-broker also uses the messagebus user, so move it
over from dbus to dbus-common
---
 meta/recipes-core/dbus/dbus_1.12.20.bb | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-core/dbus/dbus_1.12.20.bb 
b/meta/recipes-core/dbus/dbus_1.12.20.bb
index 4040fdb22a..09049301cc 100644
--- a/meta/recipes-core/dbus/dbus_1.12.20.bb
+++ b/meta/recipes-core/dbus/dbus_1.12.20.bb
@@ -24,17 +24,17 @@ python __anonymous() {
 d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
 }
 
-USERADD_PACKAGES = "${PN}"
-USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
-   --no-create-home --shell /bin/false \
-   --user-group messagebus"
+PACKAGES =+ "${PN}-lib ${PN}-common ${PN}-tools"
+
+USERADD_PACKAGES = "dbus-common"
+USERADD_PARAM_dbus-common = "--system --home ${localstatedir}/lib/dbus \
+ --no-create-home --shell /bin/false \
+ --user-group messagebus"
 
 CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf 
${sysconfdir}/dbus-1/session.conf"
 
 DEBIANNAME_${PN} = "dbus-1"
 
-PACKAGES =+ "${PN}-lib ${PN}-common ${PN}-tools"
-
 OLDPKGNAME = "dbus-x11"
 OLDPKGNAME_class-nativesdk = ""
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145091): 
https://lists.openembedded.org/g/openembedded-core/message/145091
Mute This Topic: https://lists.openembedded.org/mt/78612385/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] kernel: relocate copy of module.lds to module compilation task

2020-11-30 Thread Nicolas Dechesne

On Mon, Nov 30, 2020 at 4:34 PM Steve Sakoman  wrote:
>
> On Sun, Nov 29, 2020 at 9:38 PM Nicolas Dechesne
>  wrote:
> >
> > hi Steve and Bruce,
> >
> > On Wed, Nov 18, 2020 at 5:56 AM Bruce Ashfield  
> > wrote:
> > >
> > > From: Bruce Ashfield 
> > >
> > > There were two copies of this patch floating around, and the merged
> > > variant has the copy in the wrong place.
> > >
> > > module.lds is only created during modules_prepare, and that target is
> > > not invoked during our main build of the kernel. We aren't about to
> > > change the kernel build (there's no need), so we move the copy into
> > > the compile_kernelmodules task. After that runs, we have module.lds
> > > availble to copy.
> > >
> > > This has been tested against clean kernel + out of tree module
> > > builds, and the dependencies are correct that the file is copied
> > > before the out of tree module build starts.
> > >
> > > Signed-off-by: Bruce Ashfield 
> >
> >
> > Can we get this patch into dunfell? This is fixing a bug for BSP using
> > 5.10+ kernel, so I believe this is important for LTS. I haven't
> > attempted to backport it yet.. but let me know if you need help with
> > the backport.
>
> Is this the only patch you need to fix the 5.10+ kernel issue in dunfell?
>
> In general I haven't been taking patches that claim to be for kernels
> beyond 5.4, so I suspect there may be a handful of other patches you
> might need.

Not that I am aware! Thanks for picking it!

>
> Steve
>
> > > I had done my test builds on a branch that didn't actually contain my
> > > change, hence why 5.8 builds where blowing up.
> > >
> > > I switched to the if [ ] model, since that doesn't run afoul of the
> > > exit handler. I do find it curious that the compile task behaves so
> > > differently than the install ones (even with set +e, I couldn't use
> > > the [ ] method.
> > >
> > > Anyway, this is tested against 5.8 and 5.10 + eternal module builds
> > >
> > > Bruce
> > >
> > >  meta/classes/kernel.bbclass | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > > index ccd74e61e8..8b28ee626f 100644
> > > --- a/meta/classes/kernel.bbclass
> > > +++ b/meta/classes/kernel.bbclass
> > > @@ -391,6 +391,10 @@ do_compile_kernelmodules() {
> > > # other kernel modules and will look at this
> > > # file to do symbol lookups
> > > cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
> > > +   # 5.10+ kernels have module.lds that we need to copy for 
> > > external module builds
> > > +   if [ -e "${B}/scripts/module.lds" ]; then
> > > +   install -Dm 0644 ${B}/scripts/module.lds 
> > > ${STAGING_KERNEL_BUILDDIR}/scripts/module.lds
> > > +   fi
> > > else
> > > bbnote "no modules to compile"
> > > fi
> > > @@ -494,7 +498,6 @@ do_shared_workdir () {
> > > # Copy files required for module builds
> > > cp System.map $kerneldir/System.map-${KERNEL_VERSION}
> > > [ -e Module.symvers ] && cp Module.symvers $kerneldir/
> > > -   [ -e scripts/module.lds ] && install -Dm 0644 scripts/module.lds 
> > > $kerneldir/scripts/module.lds
> > > cp .config $kerneldir/
> > > mkdir -p $kerneldir/include/config
> > > cp include/config/kernel.release 
> > > $kerneldir/include/config/kernel.release
> > > --
> > > 2.19.1
> > >
> > >
> > > 
> > >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145090): 
https://lists.openembedded.org/g/openembedded-core/message/145090
Mute This Topic: https://lists.openembedded.org/mt/78334430/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] kernel: relocate copy of module.lds to module compilation task

2020-11-30 Thread Steve Sakoman

On Sun, Nov 29, 2020 at 9:38 PM Nicolas Dechesne
 wrote:
>
> hi Steve and Bruce,
>
> On Wed, Nov 18, 2020 at 5:56 AM Bruce Ashfield  
> wrote:
> >
> > From: Bruce Ashfield 
> >
> > There were two copies of this patch floating around, and the merged
> > variant has the copy in the wrong place.
> >
> > module.lds is only created during modules_prepare, and that target is
> > not invoked during our main build of the kernel. We aren't about to
> > change the kernel build (there's no need), so we move the copy into
> > the compile_kernelmodules task. After that runs, we have module.lds
> > availble to copy.
> >
> > This has been tested against clean kernel + out of tree module
> > builds, and the dependencies are correct that the file is copied
> > before the out of tree module build starts.
> >
> > Signed-off-by: Bruce Ashfield 
>
>
> Can we get this patch into dunfell? This is fixing a bug for BSP using
> 5.10+ kernel, so I believe this is important for LTS. I haven't
> attempted to backport it yet.. but let me know if you need help with
> the backport.

Is this the only patch you need to fix the 5.10+ kernel issue in dunfell?

In general I haven't been taking patches that claim to be for kernels
beyond 5.4, so I suspect there may be a handful of other patches you
might need.

Steve

> > I had done my test builds on a branch that didn't actually contain my
> > change, hence why 5.8 builds where blowing up.
> >
> > I switched to the if [ ] model, since that doesn't run afoul of the
> > exit handler. I do find it curious that the compile task behaves so
> > differently than the install ones (even with set +e, I couldn't use
> > the [ ] method.
> >
> > Anyway, this is tested against 5.8 and 5.10 + eternal module builds
> >
> > Bruce
> >
> >  meta/classes/kernel.bbclass | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > index ccd74e61e8..8b28ee626f 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -391,6 +391,10 @@ do_compile_kernelmodules() {
> > # other kernel modules and will look at this
> > # file to do symbol lookups
> > cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
> > +   # 5.10+ kernels have module.lds that we need to copy for 
> > external module builds
> > +   if [ -e "${B}/scripts/module.lds" ]; then
> > +   install -Dm 0644 ${B}/scripts/module.lds 
> > ${STAGING_KERNEL_BUILDDIR}/scripts/module.lds
> > +   fi
> > else
> > bbnote "no modules to compile"
> > fi
> > @@ -494,7 +498,6 @@ do_shared_workdir () {
> > # Copy files required for module builds
> > cp System.map $kerneldir/System.map-${KERNEL_VERSION}
> > [ -e Module.symvers ] && cp Module.symvers $kerneldir/
> > -   [ -e scripts/module.lds ] && install -Dm 0644 scripts/module.lds 
> > $kerneldir/scripts/module.lds
> > cp .config $kerneldir/
> > mkdir -p $kerneldir/include/config
> > cp include/config/kernel.release 
> > $kerneldir/include/config/kernel.release
> > --
> > 2.19.1
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145089): 
https://lists.openembedded.org/g/openembedded-core/message/145089
Mute This Topic: https://lists.openembedded.org/mt/78334430/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][RFC] weston-init: Stop running weston as root

2020-11-30 Thread Joshua Watt



On 11/27/20 4:17 AM, Peter Bergin wrote:


Hi,

this is a good improvement to the security, thanks for sharing this!

As the global socket now is at /run/wayland-0 users that belongs to 
group 'wayland' and want to use weston needs to set its 
XDG_RUNTIME_DIR accordingly. As probably more applications than weston 
client is using XDG_RUNTIME_DIR it is probably a bad idea to 
permanently set XDG_RUNTIME_DIR=/run? (Instead of standard 
/run/user/) In my setup I created a file 
/etc/profile.d/wayland.sh that make a symlink to /run/wayland-0 if the 
user have write permission on it.


     $ cat /etc/profile.d/wayland.sh
     # A global socket is set up that can be used for users belonging to the 
wayland
     # group to connect to weston server. Set up a soft link to that global 
socket.
     WAYLAND_SOCKET=/run/wayland-0
     [ -S $WAYLAND_SOCKET -a -w $WAYLAND_SOCKET ] && ln -s $WAYLAND_SOCKET 
$XDG_RUNTIME_DIR


Ya. I think maybe the problem is that will only work for an interactive 
shell, and wouldn't work for a service?


Also, you should avoid using the WAYLAND_SOCKET environment variable, as 
wayland clients will interpret that variable as a file descriptor number 
where a pre-connected wayland client socket is present when they start 
up (e.g. when weston launches a client with a pre-connected socket). I 
suspect the only reason this isn't causing you problems right now is 
because you aren't exporting it :)


If you want to make something compatible with what I've done here, you 
could probably get the same effect with:


 if [ -s /run/wayland-0 -a -w /run/wayland-0 ]; then

    export WAYLAND_DISPLAY=/run/wayland-0

 fi




This will make the process a bit more automatic just creating a user 
and add it to the group wayland. Is this a suitable solution? Is this 
something that we would like upstream in the weston-init package?


Maybe. I tried really hard to make it so that you make 
$XDG_RUNTIME_DIR/wayland-0 be populated from /run/wayland-0, but I was 
unable to make it work (at least with systemd). The problem I found was 
that the systemd units for dealing with XDG_RUNTIME_DIR only deal with 
users by their UID, but we only know the user name at compile time 
(since OE doesn't use fixed UIDs). As such I was unable to get systemd 
to put things in the correct (UID based) XDG_RUNTIME_DIR.





(Another side note not directly related to openembedded-core but more 
to HW specific setups (meta-freescale in my case) that I would like to 
share is that GPU device nodes also need correct permission for the 
weston user otherwise startup of weston application does not work (if 
weston using the GPU). In my case on i.Mx8 target I had to change 
/dev/galcore device node to video group (already prepared in 
udev-imx-rules package). I hope I can save time for someone else 
seeing this error message on a i.Mx system:


$ systemctl status weston
* weston.service - Weston, a Wayland compositor, as a system service
 Loaded: loaded 
(8;;file://imx8mnevk/lib/systemd/system/weston.service/lib/systemd/system/weston.service8;;;
 enabled; vendor preset: enabled)
 Active: failed (Result: exit-code) since Fri 2020-11-27 10:11:52 
UTC; 13s ago
TriggeredBy: * weston.socket
   Docs: 8;;man:weston(1)man:weston(1)8;;
 8;;man:weston.ini(5)man:weston.ini(5)8;;
 
8;;http://wayland.freedesktop.org/http://wayland.freedesktop.org/8;;
    Process: 276 ExecStart=/usr/bin/weston --modules=systemd-notify.so 
--log=/home/weston/weston.log (code=exited, status=1/FAILURE)
   Main PID: 276 (code=exited, status=1/FAILURE)

Nov 27 10:11:43 imx8mnevk systemd[1]: Starting Weston, a Wayland 
compositor, as a system service...
Nov 27 10:11:44 imx8mnevk systemd[276]: 
pam_unix(weston-autologin:session): session opened for user weston by (uid=0)
Nov 27 10:11:52 imx8mnevk systemd[1]: weston.service: Main process 
exited, code=exited, status=1/FAILURE
Nov 27 10:11:52 imx8mnevk systemd[1]: weston.service: Failed with 
result 'exit-code'.
Nov 27 10:11:52 imx8mnevk systemd[1]: Failed to start Weston, a Wayland 
compositor, as a system service.

)



That's pretty common. You could send a patch to the BSP layer to correct 
the permissions.




Best regards,
/Peter


On 2020-11-19 23:58, Joshua Watt wrote:

Running the weston compositor as the root user is an insecure default
behavior for OE-core. We can do much better, at least when using
systemd. Change the recipe to create a dedicated "weston" user and start
weston as this user. The systemd service and socket units are no longer
template units, as there were several inconsistencies in the templates.
Instead, there is now a global /run/wayland-0 socket that gets created,
and systemd will start weston on demand when a client connects to that
socket or when attempting to reach graphical.target, whichever comes
first. This also allows downstream us

Re: [OE-core] [PATCH v2] kernel: relocate copy of module.lds to module compilation task

2020-11-30 Thread Steve Sakoman

On Mon, Nov 30, 2020 at 3:24 AM Bruce Ashfield  wrote:
>
> On Mon, Nov 30, 2020 at 2:38 AM Nicolas Dechesne
>  wrote:
> >
> > hi Steve and Bruce,
> >
> > On Wed, Nov 18, 2020 at 5:56 AM Bruce Ashfield  
> > wrote:
> > >
> > > From: Bruce Ashfield 
> > >
> > > There were two copies of this patch floating around, and the merged
> > > variant has the copy in the wrong place.
> > >
> > > module.lds is only created during modules_prepare, and that target is
> > > not invoked during our main build of the kernel. We aren't about to
> > > change the kernel build (there's no need), so we move the copy into
> > > the compile_kernelmodules task. After that runs, we have module.lds
> > > availble to copy.
> > >
> > > This has been tested against clean kernel + out of tree module
> > > builds, and the dependencies are correct that the file is copied
> > > before the out of tree module build starts.
> > >
> > > Signed-off-by: Bruce Ashfield 
> >
> >
> > Can we get this patch into dunfell? This is fixing a bug for BSP using
> > 5.10+ kernel, so I believe this is important for LTS.

Certainly!

> For a backport, you need this patch and also the one that it is tweaking:
> [kernel: provide module.lds for out of tree builds in v5.10+], but I didn't
> check to see if Steve had already grabbed that one.
>
> I also don't see any issue with this, and the backport is simple enough since
> it is additive to what we copy into the artifacts.
>
> Like building on newer distros, we will eventually run into newer kernel
> support that we can't backport or support on dunfell .. but this isn't that
> case!
>
> Steve: it should be a simple cherry pick, if it isn't, let me know and I can
> send the patches.

A simple cherry-pick was successful.  Will start testing later this morning.

Steve

> > >
> > > v2:
> > >
> > > I had done my test builds on a branch that didn't actually contain my
> > > change, hence why 5.8 builds where blowing up.
> > >
> > > I switched to the if [ ] model, since that doesn't run afoul of the
> > > exit handler. I do find it curious that the compile task behaves so
> > > differently than the install ones (even with set +e, I couldn't use
> > > the [ ] method.
> > >
> > > Anyway, this is tested against 5.8 and 5.10 + eternal module builds
> > >
> > > Bruce
> > >
> > >  meta/classes/kernel.bbclass | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > > index ccd74e61e8..8b28ee626f 100644
> > > --- a/meta/classes/kernel.bbclass
> > > +++ b/meta/classes/kernel.bbclass
> > > @@ -391,6 +391,10 @@ do_compile_kernelmodules() {
> > > # other kernel modules and will look at this
> > > # file to do symbol lookups
> > > cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
> > > +   # 5.10+ kernels have module.lds that we need to copy for 
> > > external module builds
> > > +   if [ -e "${B}/scripts/module.lds" ]; then
> > > +   install -Dm 0644 ${B}/scripts/module.lds 
> > > ${STAGING_KERNEL_BUILDDIR}/scripts/module.lds
> > > +   fi
> > > else
> > > bbnote "no modules to compile"
> > > fi
> > > @@ -494,7 +498,6 @@ do_shared_workdir () {
> > > # Copy files required for module builds
> > > cp System.map $kerneldir/System.map-${KERNEL_VERSION}
> > > [ -e Module.symvers ] && cp Module.symvers $kerneldir/
> > > -   [ -e scripts/module.lds ] && install -Dm 0644 scripts/module.lds 
> > > $kerneldir/scripts/module.lds
> > > cp .config $kerneldir/
> > > mkdir -p $kerneldir/include/config
> > > cp include/config/kernel.release 
> > > $kerneldir/include/config/kernel.release
> > > --
> > > 2.19.1
> > >
> > >
> > > 
> > >
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145087): 
https://lists.openembedded.org/g/openembedded-core/message/145087
Mute This Topic: https://lists.openembedded.org/mt/78334430/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v5 2/5] python3-numpy: Add ptest

2020-11-30 Thread Ross Burton

Why are all the patches from this not squashed into this?  We don't
need to see the bugs you fixed.

Ross

On Sun, 29 Nov 2020 at 07:48, Khem Raj  wrote:
>
> Since 1.15, numpy have replaced nose with pytest testing framework
> it additionally needs hypothesis and sortedcontainers modules
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-devtools/python-numpy/files/run-ptest | 5 +
>  meta/recipes-devtools/python-numpy/python3-numpy_1.19.4.bb | 7 +--
>  2 files changed, 10 insertions(+), 2 deletions(-)
>  create mode 100644 meta/recipes-devtools/python-numpy/files/run-ptest
>
> diff --git a/meta/recipes-devtools/python-numpy/files/run-ptest 
> b/meta/recipes-devtools/python-numpy/files/run-ptest
> new file mode 100644
> index 00..9a1c72aeb1
> --- /dev/null
> +++ b/meta/recipes-devtools/python-numpy/files/run-ptest
> @@ -0,0 +1,5 @@
> +#!/usr/bin/env python3
> +
> +import numpy
> +numpy.test(label='full', verbose=2)
> +
> diff --git a/meta/recipes-devtools/python-numpy/python3-numpy_1.19.4.bb 
> b/meta/recipes-devtools/python-numpy/python3-numpy_1.19.4.bb
> index d54f2f6c18..b484e7cddc 100644
> --- a/meta/recipes-devtools/python-numpy/python3-numpy_1.19.4.bb
> +++ b/meta/recipes-devtools/python-numpy/python3-numpy_1.19.4.bb
> @@ -8,6 +8,7 @@ SRCNAME = "numpy"
>  SRC_URI = 
> "https://github.com/${SRCNAME}/${SRCNAME}/releases/download/v${PV}/${SRCNAME}-${PV}.tar.gz
>  \
> 
> file://0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch \
> file://0001-numpy-core-Define-RISCV-32-support.patch \
> +   file://run-ptest \
>  "
>  SRC_URI[sha256sum] = 
> "fe836a685d6838dbb3f603caef01183ea98e88febf4ce956a2ea484a75378413"
>
> @@ -16,7 +17,7 @@ UPSTREAM_CHECK_REGEX = "(?P\d+(\.\d+)+)\.tar"
>
>  DEPENDS += "python3-cython-native"
>
> -inherit setuptools3
> +inherit ptest setuptools3
>
>  S = "${WORKDIR}/numpy-${PV}"
>
> @@ -30,7 +31,6 @@ RDEPENDS_${PN} = "${PYTHON_PN}-unittest \
>${PYTHON_PN}-pprint \
>${PYTHON_PN}-pickle \
>${PYTHON_PN}-shell \
> -  ${PYTHON_PN}-nose \
>${PYTHON_PN}-doctest \
>${PYTHON_PN}-datetime \
>${PYTHON_PN}-distutils \
> @@ -39,6 +39,9 @@ RDEPENDS_${PN} = "${PYTHON_PN}-unittest \
>${PYTHON_PN}-netclient \
>${PYTHON_PN}-numbers \
>${PYTHON_PN}-pydoc \
> +  ${PYTHON_PN}-pytest \
> +  ${PYTHON_PN}-hypothesis \
> +  ${PYTHON_PN}-sortedcontainers \
>${PYTHON_PN}-pkgutil \
>${PYTHON_PN}-email \
>${PYTHON_PN}-compression \
> --
> 2.29.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145086): 
https://lists.openembedded.org/g/openembedded-core/message/145086
Mute This Topic: https://lists.openembedded.org/mt/78581725/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] lz4: Use the new branch naming from upstream

2020-11-30 Thread Richard Purdie

On Mon, 2020-11-30 at 14:51 +0100, Quentin Schulz wrote:
> Hi Richard,
> 
> On Mon, Nov 30, 2020 at 01:47:03PM +, Richard Purdie wrote:
> > Upstream renamed master -> dev, update SRC_URI to match.
> > 
> 
> Wondering if "release" branch does not make more sense?

Good question. Dev had the revision we're using in so I didn't look
further. In practise I'm not sure it matters too much...

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145085): 
https://lists.openembedded.org/g/openembedded-core/message/145085
Mute This Topic: https://lists.openembedded.org/mt/78608112/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] lz4: Use the new branch naming from upstream

2020-11-30 Thread Quentin Schulz

Hi Richard,

On Mon, Nov 30, 2020 at 01:47:03PM +, Richard Purdie wrote:
> Upstream renamed master -> dev, update SRC_URI to match.
> 

Wondering if "release" branch does not make more sense?

Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145084): 
https://lists.openembedded.org/g/openembedded-core/message/145084
Mute This Topic: https://lists.openembedded.org/mt/78608112/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] lz4: Use the new branch naming from upstream

2020-11-30 Thread Richard Purdie

Upstream renamed master -> dev, update SRC_URI to match.

[YOCTO #14135]

Signed-off-by: Richard Purdie 
---
 meta/recipes-support/lz4/lz4_1.9.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/lz4/lz4_1.9.2.bb 
b/meta/recipes-support/lz4/lz4_1.9.2.bb
index 6510156ed0c..455d2a5141f 100644
--- a/meta/recipes-support/lz4/lz4_1.9.2.bb
+++ b/meta/recipes-support/lz4/lz4_1.9.2.bb
@@ -11,7 +11,7 @@ PE = "1"
 
 SRCREV = "fdf2ef5809ca875c454510610764d9125ef2ebbd"
 
-SRC_URI = "git://github.com/lz4/lz4.git \
+SRC_URI = "git://github.com/lz4/lz4.git;branch=dev \
file://run-ptest \
"
 UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145083): 
https://lists.openembedded.org/g/openembedded-core/message/145083
Mute This Topic: https://lists.openembedded.org/mt/78608112/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] kernel: relocate copy of module.lds to module compilation task

2020-11-30 Thread Bruce Ashfield

On Mon, Nov 30, 2020 at 2:38 AM Nicolas Dechesne
 wrote:
>
> hi Steve and Bruce,
>
> On Wed, Nov 18, 2020 at 5:56 AM Bruce Ashfield  
> wrote:
> >
> > From: Bruce Ashfield 
> >
> > There were two copies of this patch floating around, and the merged
> > variant has the copy in the wrong place.
> >
> > module.lds is only created during modules_prepare, and that target is
> > not invoked during our main build of the kernel. We aren't about to
> > change the kernel build (there's no need), so we move the copy into
> > the compile_kernelmodules task. After that runs, we have module.lds
> > availble to copy.
> >
> > This has been tested against clean kernel + out of tree module
> > builds, and the dependencies are correct that the file is copied
> > before the out of tree module build starts.
> >
> > Signed-off-by: Bruce Ashfield 
>
>
> Can we get this patch into dunfell? This is fixing a bug for BSP using
> 5.10+ kernel, so I believe this is important for LTS. I haven't
> attempted to backport it yet.. but let me know if you need help with
> the backport.

For a backport, you need this patch and also the one that it is tweaking:
[kernel: provide module.lds for out of tree builds in v5.10+], but I didn't
check to see if Steve had already grabbed that one.

I also don't see any issue with this, and the backport is simple enough since
it is additive to what we copy into the artifacts.

Like building on newer distros, we will eventually run into newer kernel
support that we can't backport or support on dunfell .. but this isn't that
case!

Steve: it should be a simple cherry pick, if it isn't, let me know and I can
send the patches.

Cheers,

Bruce

>
>
> > ---
> >
> > v2:
> >
> > I had done my test builds on a branch that didn't actually contain my
> > change, hence why 5.8 builds where blowing up.
> >
> > I switched to the if [ ] model, since that doesn't run afoul of the
> > exit handler. I do find it curious that the compile task behaves so
> > differently than the install ones (even with set +e, I couldn't use
> > the [ ] method.
> >
> > Anyway, this is tested against 5.8 and 5.10 + eternal module builds
> >
> > Bruce
> >
> >  meta/classes/kernel.bbclass | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > index ccd74e61e8..8b28ee626f 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -391,6 +391,10 @@ do_compile_kernelmodules() {
> > # other kernel modules and will look at this
> > # file to do symbol lookups
> > cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
> > +   # 5.10+ kernels have module.lds that we need to copy for 
> > external module builds
> > +   if [ -e "${B}/scripts/module.lds" ]; then
> > +   install -Dm 0644 ${B}/scripts/module.lds 
> > ${STAGING_KERNEL_BUILDDIR}/scripts/module.lds
> > +   fi
> > else
> > bbnote "no modules to compile"
> > fi
> > @@ -494,7 +498,6 @@ do_shared_workdir () {
> > # Copy files required for module builds
> > cp System.map $kerneldir/System.map-${KERNEL_VERSION}
> > [ -e Module.symvers ] && cp Module.symvers $kerneldir/
> > -   [ -e scripts/module.lds ] && install -Dm 0644 scripts/module.lds 
> > $kerneldir/scripts/module.lds
> > cp .config $kerneldir/
> > mkdir -p $kerneldir/include/config
> > cp include/config/kernel.release 
> > $kerneldir/include/config/kernel.release
> > --
> > 2.19.1
> >
> >
> > 
> >



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145082): 
https://lists.openembedded.org/g/openembedded-core/message/145082
Mute This Topic: https://lists.openembedded.org/mt/78334430/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCHv2 1/4] pseudo: Simplify pseudo_client_ignore_path_chroot()

2020-11-30 Thread Richard Purdie

Hi Peter,

On Wed, 2020-11-25 at 14:48 +0100, Peter Kjellerstedt wrote:
> This also plugs a memory leak in pseudo_client_ignore_path_chroot().
> 
> Signed-off-by: Peter Kjellerstedt 

I make no claim to understand what happened but I tried patches 1 and 2
in a build over the weekend and with the first two present:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1602
https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1584
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1586
https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/1610

I then removed this one leaving only patch 2 and the build was fine.

So there is something odd in this patch but I've not looked into what
or why only selftest is affected.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145081): 
https://lists.openembedded.org/g/openembedded-core/message/145081
Mute This Topic: https://lists.openembedded.org/mt/78499442/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball

2020-11-30 Thread Ross Burton

Some of the selftests failed over the weekend with "access denied" errors
fetching this tarball.  Instead of relying on upstream when fetching the
tarball, use the Yocto source mirrors instead.

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/selftest/cases/devtool.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/devtool.py 
b/meta/lib/oeqa/selftest/cases/devtool.py
index d3d2e04c20e..b8edc897687 100644
--- a/meta/lib/oeqa/selftest/cases/devtool.py
+++ b/meta/lib/oeqa/selftest/cases/devtool.py
@@ -269,7 +269,7 @@ class DevtoolAddTests(DevtoolBase):
 self.track_for_cleanup(tempdir)
 pn = 'pv'
 pv = '1.5.3'
-url = 'http://www.ivarch.com/programs/sources/pv-1.5.3.tar.bz2'
+url = 
'http://downloads.yoctoproject.org/mirror/sources/pv-1.5.3.tar.bz2'
 result = runCmd('wget %s' % url, cwd=tempdir)
 result = runCmd('tar xfv %s' % os.path.basename(url), cwd=tempdir)
 srcdir = os.path.join(tempdir, '%s-%s' % (pn, pv))
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145080): 
https://lists.openembedded.org/g/openembedded-core/message/145080
Mute This Topic: https://lists.openembedded.org/mt/78605904/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCHv2 3/4] bitbake.conf: Canonicalize paths in PSEUDO_IGNORE_PATHS

[OE-core] [meta-oe][PATCH v2] procps: split into binary subpackages

[OE-core] [meta-oe][PATCH] procps: split into binary subpackages

[OE-core] [meta-oe][PATCH v3] net-tools: split into binary packages

Re: [OE-core] [PATCH 1/1] classes/kernel*: allow disabling symlink creation

[OE-core][master][PATCH] qemu: CVE-2020-29129 CVE-2020-29130

[OE-core] Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)

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

Re: [OE-core] [PATCHv2 1/4] pseudo: Simplify pseudo_client_ignore_path_chroot()

[OE-core] [PATCH 1/2] linux-firmware: upgrade 20201022 -> 20201118

[OE-core] [PATCH 2/2] linux-firmware: package ath11k firmware

[OE-Core][master][gatesgarth][PATCH] populate_sdk_ext: use CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg

Re: [OE-core] [PATCH 00/18] Move python3-pytest to oe-core

Re: [OE-core] [PATCH 2/2] connman: set service to conflict with systemd-networkd

Re: [OE-core] [PATCHv2 3/4] bitbake.conf: Canonicalize paths in PSEUDO_IGNORE_PATHS

Re: [OE-core] Dunfell CVE reduction fun: December raffle

[OE-core] CVE raffle: collision avoidance

[OE-core] Dunfell CVE reduction fun: December raffle

Re: [OE-core] [PATCH v5 2/5] python3-numpy: Add ptest

[OE-core] [PATCH] dbus: move messagebus user to dbus-common package

Re: [OE-core] [PATCH v2] kernel: relocate copy of module.lds to module compilation task

Re: [OE-core] [PATCH v2] kernel: relocate copy of module.lds to module compilation task

Re: [OE-core][RFC] weston-init: Stop running weston as root

Re: [OE-core] [PATCH v2] kernel: relocate copy of module.lds to module compilation task

Re: [OE-core] [PATCH v5 2/5] python3-numpy: Add ptest

Re: [OE-core] [PATCH] lz4: Use the new branch naming from upstream

Re: [OE-core] [PATCH] lz4: Use the new branch naming from upstream

[OE-core] [PATCH] lz4: Use the new branch naming from upstream

Re: [OE-core] [PATCH v2] kernel: relocate copy of module.lds to module compilation task

Re: [OE-core] [PATCHv2 1/4] pseudo: Simplify pseudo_client_ignore_path_chroot()

[OE-core] [PATCH] oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball

31 matches

Site Navigation

Mail list logo

Footer information