Re: [OE-core] [PATCH v2 4/4] weston: Set depends to the virtual needed not explicitly on Mesa
On Thu, Sep 26, 2019 at 10:19:12AM +0200, Stefan Agner wrote:
> On 2019-09-17 15:10, Andrew F. Davis via Openembedded-core wrote:
> > The dependency is for EGL and GLES2 libraries. On some systems these
> > are not provided by Mesa, list what is actually needed so the system
> > can choose the correct provider.
>
> Unfortunately I saw that a bit late, but this is breaking our use case.
>
> Weston works perfectly fine on non-GPU systems without EGL/OpenGL ES
> using pixman renderer. Currently libgbm is still a compile time
> dependency, but I have a merge request pending which should drop this
> dependency, then the DRM backend can be compiled fine with only KMS
> support.
Hi, Stefan,
Can you please provide Weston configuration logs when it gets built with
pixman and w/o EGL/GLES? Thanks.
--
Denys
> > Signed-off-by: Andrew F. Davis
> > Acked-by: Denys Dmytriyenko
> > ---
> >
> > Changes from v1:
> > - s/gles2/libgles2
> >
> > meta/recipes-graphics/wayland/weston_7.0.0.bb | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-graphics/wayland/weston_7.0.0.bb
> > b/meta/recipes-graphics/wayland/weston_7.0.0.bb
> > index 5d2a9336f3..f9efdbd20a 100644
> > --- a/meta/recipes-graphics/wayland/weston_7.0.0.bb
> > +++ b/meta/recipes-graphics/wayland/weston_7.0.0.bb
> > @@ -36,9 +36,9 @@ PACKAGECONFIG ??=
> > "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'kms fbdev
> > # Compositor choices
> > #
> > # Weston on KMS
> > -PACKAGECONFIG[kms] = "-Dbackend-drm=true,-Dbackend-drm=false,drm udev
> > virtual/mesa virtual/libgbm mtdev"
> > +PACKAGECONFIG[kms] = "-Dbackend-drm=true,-Dbackend-drm=false,drm udev
> > virtual/egl virtual/libgles2 virtual/libgbm mtdev"
> > # Weston on Wayland (nested Weston)
> > -PACKAGECONFIG[wayland] =
> > "-Dbackend-wayland=true,-Dbackend-wayland=false,virtual/mesa"
> > +PACKAGECONFIG[wayland] =
> > "-Dbackend-wayland=true,-Dbackend-wayland=false,virtual/egl
> > virtual/libgles2"
> > # Weston on X11
> > PACKAGECONFIG[x11] =
> > "-Dbackend-x11=true,-Dbackend-x11=false,virtual/libx11 libxcb libxcb
> > libxcursor cairo"
> > # Headless Weston
> > --
> > 2.17.1
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] icecc: Export ICECC_CC and friends via wrapper-script
By exporting ICECC_CC, ICECC_CXX, and ICECC_VERSION in a wrapper-script,
and putting this wrapper-script in the PATH, the Makefiles generated by CMake or
the autotools are able to function correctly outside of bitbake.
This provides a convenient developer workflow in which the
modify-compile-unittest cycle can happen directly in the ${B} directory.
The `rm -f $ICE_PATH/$compiler` line is transitional,
and can go at some later date (October 2020 or later, perhaps).
Signed-off-by: Douglas Royds
---
meta/classes/icecc.bbclass | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index 9dbb4b1559..e74d798fd0 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -352,17 +352,6 @@ set_icecc_env() {
return
fi
-# Create symlinks to icecc in the recipe-sysroot directory
-mkdir -p ${ICE_PATH}
-if [ -n "${KERNEL_CC}" ]; then
-compilers="${@get_cross_kernel_cc(bb,d)}"
-else
-compilers="${HOST_PREFIX}gcc ${HOST_PREFIX}g++"
-fi
-for compiler in $compilers; do
-ln -sf ${ICECC_BIN} ${ICE_PATH}/$compiler
-done
-
ICECC_CC="${@icecc_get_and_check_tool(bb, d, "gcc")}"
ICECC_CXX="${@icecc_get_and_check_tool(bb, d, "g++")}"
# cannot use icecc_get_and_check_tool here because it assumes as without
target_sys prefix
@@ -381,6 +370,26 @@ set_icecc_env() {
return
fi
+# Create symlinks to icecc and wrapper-scripts in the recipe-sysroot
directory
+mkdir -p $ICE_PATH/symlinks
+if [ -n "${KERNEL_CC}" ]; then
+compilers="${@get_cross_kernel_cc(bb,d)}"
+else
+compilers="${HOST_PREFIX}gcc ${HOST_PREFIX}g++"
+fi
+for compiler in $compilers; do
+ln -sf $ICECC_BIN $ICE_PATH/symlinks/$compiler
+rm -f $ICE_PATH/$compiler
+cat <<-__EOF__ > $ICE_PATH/$compiler
+ #!/bin/sh -e
+ export ICECC_VERSION=$ICECC_VERSION
+ export ICECC_CC=$ICECC_CC
+ export ICECC_CXX=$ICECC_CXX
+ $ICE_PATH/symlinks/$compiler "\$@"
+ __EOF__
+chmod 775 $ICE_PATH/$compiler
+done
+
ICECC_AS="`${ICECC_CC} -print-prog-name=as`"
# for target recipes should return something like:
#
/OE/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/arm920tt-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.8.2/as
@@ -413,7 +422,6 @@ set_icecc_env() {
export CCACHE_PATH="$PATH"
export CCACHE_DISABLE="1"
-export ICECC_VERSION ICECC_CC ICECC_CXX
export PATH="$ICE_PATH:$PATH"
bbnote "Using icecc path: $ICE_PATH"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [warrior-next 1/2] qemuarm64: Add QB_CPU_KVM to allow kvm acceleration
From: Richard Purdie This allows kvm acceleration on arm systems that support it. "host" is the best option I can find right now to attempt to use the acceleration. It potentially might not be correct but arm systems are sensitive to the correct values and I don't want to encode the autobuilders CPU type here. Signed-off-by: Richard Purdie (cherry picked from commit f13788541f64774a586971ed57699e4397b38b32) Signed-off-by: Armin Kuster --- meta/conf/machine/qemuarm64.conf | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf index 5c8aac1..353ac92 100644 --- a/meta/conf/machine/qemuarm64.conf +++ b/meta/conf/machine/qemuarm64.conf @@ -14,6 +14,7 @@ QB_SYSTEM_NAME = "qemu-system-aarch64" QB_MEM = "-m 512" QB_MACHINE = "-machine virt" QB_CPU = "-cpu cortex-a57" +QB_CPU_KVM = "-cpu host" # Standard Serial console QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0" # For graphics to work we need to define the VGA device as well as the necessary USB devices -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [warrior-next 2/2] runqemu: Add support for kvm on aarch64
From: Richard Purdie
The main issue is to make the x86 checks apply to x86 targets only. We may
end up with better checks on other architectures but this adapts the code to
allow for that and its still controlled by whether QB_CPU_KVM is set.
The code needed minor refactoring so the qemu-system-XXX name is set
earlier so the kvm code can use it.
Signed-off-by: Richard Purdie
Signed-off-by: Armin Kuster
---
scripts/runqemu | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 19fd521..af90c01 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -491,12 +491,13 @@ class BaseConfig(object):
yocto_paravirt_kvm_wiki =
"https://wiki.yoctoproject.org/wiki/Running_an_x86_Yocto_Linux_image_under_QEMU_KVM;
dev_kvm = '/dev/kvm'
dev_vhost = '/dev/vhost-net'
-with open('/proc/cpuinfo', 'r') as f:
-kvm_cap = re.search('vmx|svm', "".join(f.readlines()))
-if not kvm_cap:
-logger.error("You are trying to enable KVM on a cpu without VT
support.")
-logger.error("Remove kvm from the command-line, or refer:")
-raise RunQemuError(yocto_kvm_wiki)
+if self.qemu_system.endswith(('i386', 'x86_64')):
+with open('/proc/cpuinfo', 'r') as f:
+kvm_cap = re.search('vmx|svm', "".join(f.readlines()))
+if not kvm_cap:
+logger.error("You are trying to enable KVM on a cpu without VT
support.")
+logger.error("Remove kvm from the command-line, or refer:")
+raise RunQemuError(yocto_kvm_wiki)
if not os.path.exists(dev_kvm):
logger.error("Missing KVM device. Have you inserted kvm modules?")
@@ -709,6 +710,7 @@ class BaseConfig(object):
else:
os.putenv('QEMU_AUDIO_DRV', 'none')
+self.check_qemu_system()
self.check_kvm()
self.check_fstype()
self.check_rootfs()
@@ -1134,21 +1136,23 @@ class BaseConfig(object):
return 'qemu-system-%s' % qbsys
-def setup_final(self):
+def check_qemu_system(self):
qemu_system = self.get('QB_SYSTEM_NAME')
if not qemu_system:
qemu_system = self.guess_qb_system()
if not qemu_system:
raise RunQemuError("Failed to boot, QB_SYSTEM_NAME is NULL!")
+self.qemu_system = qemu_system
-qemu_bin = os.path.join(self.bindir_native, qemu_system)
+def setup_final(self):
+qemu_bin = os.path.join(self.bindir_native, self.qemu_system)
# It is possible to have qemu-native in ASSUME_PROVIDED, and it won't
# find QEMU in sysroot, it needs to use host's qemu.
if not os.path.exists(qemu_bin):
logger.info("QEMU binary not found in %s, trying host's QEMU" %
qemu_bin)
for path in (os.environ['PATH'] or '').split(':'):
-qemu_bin_tmp = os.path.join(path, qemu_system)
+qemu_bin_tmp = os.path.join(path, self.qemu_system)
logger.info("Trying: %s" % qemu_bin_tmp)
if os.path.exists(qemu_bin_tmp):
qemu_bin = qemu_bin_tmp
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [warrior-next 0/2] warrior pull request
These two commits fix the qemuarm64-ptest failures on the arm host The following changes since commit 8c87e78547c598cada1bce92e7b25d85b994e2eb: cve-check: backport rewrite from master (2019-09-29 21:38:22 -0700) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib stable/warrior-next http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/warrior-next Richard Purdie (2): qemuarm64: Add QB_CPU_KVM to allow kvm acceleration runqemu: Add support for kvm on aarch64 meta/conf/machine/qemuarm64.conf | 1 + scripts/runqemu | 22 +- 2 files changed, 14 insertions(+), 9 deletions(-) -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][thud][PATCH] perl: Fix CVE-2018-18311 to 18314
From: Dan Tran
Signed-off-by: Dan Tran
---
.../perl/perl/CVE-2018-18311.patch| 183
.../perl/perl/CVE-2018-18312.patch| Bin 0 -> 2125 bytes
.../perl/perl/CVE-2018-18313.patch| 60
.../perl/perl/CVE-2018-18314.patch| 271 ++
meta/recipes-devtools/perl/perl_5.24.4.bb | 4 +
5 files changed, 518 insertions(+)
create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-18311.patch
create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-18312.patch
create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-18313.patch
create mode 100644 meta/recipes-devtools/perl/perl/CVE-2018-18314.patch
diff --git a/meta/recipes-devtools/perl/perl/CVE-2018-18311.patch
b/meta/recipes-devtools/perl/perl/CVE-2018-18311.patch
new file mode 100644
index 00..ba8cf151fd
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/CVE-2018-18311.patch
@@ -0,0 +1,183 @@
+From 4706b65d7c835c0bb219db160fbcdbcd98efab2d Mon Sep 17 00:00:00 2001
+From: David Mitchell
+Date: Fri, 29 Jun 2018 13:37:03 +0100
+Subject: [PATCH] Perl_my_setenv(); handle integer wrap
+
+RT #133204
+
+Wean this function off int/I32 and onto UV/Size_t.
+Also, replace all malloc-ish calls with a wrapper that does
+overflow checks,
+
+In particular, it was doing (nlen + vlen + 2) which could wrap when
+the combined length of the environment variable name and value
+exceeded around 0x7fff.
+
+The wrapper check function is probably overkill, but belt and braces...
+
+NB this function has several variant parts, #ifdef'ed by platform
+type; I have blindly changed the parts that aren't compiled under linux.
+
+(cherry picked from commit 34716e2a6ee2af96078d62b065b7785c001194be)
+
+CVE: CVE-2018-18311
+Upstream-Status: Backport
+[https://perl5.git.perl.org/perl.git/commit/5737d31aac51360cc1eb412ef059e36147c9d6d6]
+
+Signed-off-by: Dan Tran
+---
+ util.c | 76 --
+ 1 file changed, 53 insertions(+), 23 deletions(-)
+
+diff --git a/util.c b/util.c
+index 7c3d271f51..27f4eddf3b 100644
+--- a/util.c
b/util.c
+@@ -2160,8 +2160,40 @@ Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer, const
char *const bits,
+*(s+(nlen+1+vlen)) = '\0'
+
+ #ifdef USE_ENVIRON_ARRAY
+- /* VMS' my_setenv() is in vms.c */
++
++/* small wrapper for use by Perl_my_setenv that mallocs, or reallocs if
++ * 'current' is non-null, with up to three sizes that are added together.
++ * It handles integer overflow.
++ */
++static char *
++S_env_alloc(void *current, Size_t l1, Size_t l2, Size_t l3, Size_t size)
++{
++void *p;
++Size_t sl, l = l1 + l2;
++
++if (l < l2)
++goto panic;
++l += l3;
++if (l < l3)
++goto panic;
++sl = l * size;
++if (sl < l)
++goto panic;
++
++p = current
++? safesysrealloc(current, sl)
++: safesysmalloc(sl);
++if (p)
++return (char*)p;
++
++ panic:
++croak_memory_wrap();
++}
++
++
++/* VMS' my_setenv() is in vms.c */
+ #if !defined(WIN32) && !defined(NETWARE)
++
+ void
+ Perl_my_setenv(pTHX_ const char *nam, const char *val)
+ {
+@@ -2177,28 +2209,27 @@ Perl_my_setenv(pTHX_ const char *nam, const char *val)
+ #ifndef PERL_USE_SAFE_PUTENV
+ if (!PL_use_safe_putenv) {
+ /* most putenv()s leak, so we manipulate environ directly */
+-I32 i;
+-const I32 len = strlen(nam);
+-int nlen, vlen;
++UV i;
++Size_t vlen, nlen = strlen(nam);
+
+ /* where does it go? */
+ for (i = 0; environ[i]; i++) {
+-if (strnEQ(environ[i],nam,len) && environ[i][len] == '=')
++if (strnEQ(environ[i], nam, nlen) && environ[i][nlen] == '=')
+ break;
+ }
+
+ if (environ == PL_origenviron) { /* need we copy environment? */
+-I32 j;
+-I32 max;
++UV j, max;
+ char **tmpenv;
+
+ max = i;
+ while (environ[max])
+ max++;
+-tmpenv = (char**)safesysmalloc((max+2) * sizeof(char*));
++/* XXX shouldn't that be max+1 rather than max+2 ??? - DAPM */
++tmpenv = (char**)S_env_alloc(NULL, max, 2, 0, sizeof(char*));
+ for (j=0; jdjW4{TZ12mg8G4oWUl%#%lZd(l&4=
z*5HLeNYcMR3Gs}#2$R5jCM)=(tg4dL9f}@xHEWz!=C6#`Oo>EejDh++4kca$
zo|jDh#P`4^0U^fOX7y2|DuIjNj?Yitf#*(38ko3$(E3O(s4?Zq`beIy8Wqm5nlt
zli%MYfP<}ZZ7-U5)cCOOloYJC`gs|`f1%tWn2_Wt-Hi^HR#mIOXX-v@3m)X
zj+?f1jnkB8JdS*t(TLzX35cI!gZ5zPm0{bq0aE0+SUV|fpF6;C7@%A!@XeRC=yFHF9ZX@Q9|I_4
zWhFXD3)bX4a2e+jPT`HAVz3Dxudy+cFGZW*OKvIt5H)?(D4|XrpYnxB9xZ@DQX~1I|6Y$VI-`CrHtZ(3E;4#M05!jv|g>)RkXiEfuOeuJ~Og9quD-
z=F{o)&15G=qy4Xouui);{BZK_`1JUE_@H6IYzC%fTBvB)PjR=a2ib3;_aa%v
z@(yOuu`99c7vI=R-l`Tb`n(d$7Aps-uSkA=8u;fKUAfOVyCjf^$0VJmK5?928cpJm
zr8In+gy)*uR6OVEgv66^03#eDor?MvekjVkSk~o@;7eZWnwY`RJT{?HU=q`ULp?zP
z$U~>JM%q?wvn;ScFg9z64VS^-M?(J`jG>i$I7kLM_*zu4)qe@jRWE6bwCrk=Z`
Re: [OE-core] [yocto] Xilinx/meta-jupyter layer
FYI I've just changed the layer index entry to point to the new repo. New content should be indexed in a few hours. Thanks for working this out! Dmitry: sorry, for clarity did you mean a separate mailing list or one of the YP / OE ones ? Cheers, Paul On Saturday, 28 September 2019 9:52:26 AM NZDT Dmitry Kargin wrote: > Nice job! > > You have my permission, if it is needed to change > https://layers.openembedded.org/layerindex/branch/master/layer/meta-jupyter/ > links to your repository. > > >Would you recommend maintaining this layer separately or... > I'd like to keep it separately from meta- and openembedded. > > >Would you suggest having a separate mailing list > meta-jupyter mailing list is fine. > > On Fri, 27 Sep 2019 at 23:12, Chandana Kalluri wrote: > > > Hello all, > > > > https://github.com/Xilinx/meta-jupyter is a meta-jupyter layer containing > > recipes for jupyter notebook. The initial recipes are based of Dmitry > > Kargin's meta-jupyter layer > > https://layers.openembedded.org/layerindex/branch/master/layer/meta-jupyter/. > > This layer has not been updated for a while. > > > > The Xilinx/meta-jupyter layer also adds recipes for python3 based > > notebooks apart from existing python2 based notebooks. > > This layer has been tested using Yocto thud layer and by running jupyter > > notebooks on Ultra96 community boards. > > We would like to maintain Xilinx/meta-jupyter layer actively and welcome > > contributions to this layer either through pull requests or via patches > > sent to meta-xilinx mailing list until a mailing list for meta-jupyter is > > in place. In the next cycle we will deprecate python2 recipes. > > > > A question to community, > > - Would you recommend maintaining this layer separately in the current > > github.com/Xilinx location or be included under meta- openembedded layers. > > - Would you suggest having a separate mailing list ? > > > > Thanks, > > Chandana > > > > > -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] layer.conf: Add xserver-nodm-init to SIGGEN_EXCLUDERECIPES_ABISAFE
Found signature differences when same machine is used as a copy see ERROR: xscreensaver different signature for task do_package_write_ipk.sigdata between qemux86copy and qemux86 Hash for dependent task x11-common/xserver-nodm-init_3.0.bb:do_packagedata changed from de0944d4fcaeed0efdb143a18cc406bd043469ae291de1704a999bc878a7691c to ba7bdaf35860ba5bf5a5f4ce06379a77c88eb9806e09a1fc5373933888a46507 Signed-off-by: Khem Raj --- meta/conf/layer.conf | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf index 27893b633e..a13c8dc9b2 100644 --- a/meta/conf/layer.conf +++ b/meta/conf/layer.conf @@ -44,6 +44,7 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += " \ opkg-utils \ gstreamer1.0-meta-base \ ca-certificates \ + xserver-nodm-init \ " SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \ -- 2.23.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] opkg: remove pathfinder PACKAGECONFIG option
From: Trevor Gamblin
pathfinder has no recipe and its last update was in 2013
(see http://freshmeat.sourceforge.net/projects/pathfinder),
so it should be removed from the list of PACKAGECONFIG options
for opkg. --disable-pathfinder is added to EXTRA_OECONF for
good measure.
Signed-off-by: Trevor Gamblin
---
meta/recipes-devtools/opkg/opkg_0.4.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/opkg/opkg_0.4.1.bb
b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
index 6270862..10c2628 100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.1.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
@@ -37,9 +37,9 @@ PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl openssl"
PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
-PACKAGECONFIG[pathfinder] =
"--enable-pathfinder,--disable-pathfinder,pathfinder"
PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
+EXTRA_OECONF += " --disable-pathfinder"
EXTRA_OECONF_class-native =
"--localstatedir=/${@os.path.relpath('${localstatedir}',
'${STAGING_DIR_NATIVE}')} --sysconfdir=/${@os.path.relpath('${sysconfdir}',
'${STAGING_DIR_NATIVE}')}"
# Release tarball has unused binaries on the tests folder, automatically
created by automake.
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Fwd: [yocto] Schedule Announced for Yocto Project Summit Europe 2019
The schedule looks really good. Lot's of talks from people doing work with OpenEmbedded and the Yocto Project,. Philip Forwarded Message Subject: [yocto] Schedule Announced for Yocto Project Summit Europe 2019 Date: Fri, 27 Sep 2019 04:33:12 + From: Volosincu, Andreea S To: Yocto list discussion We're excited to announce the amazing sessions scheduled for the Yocto Project Summit 2019. Sessions include: *Yocto Project and CVEs *Transitioning from long term stable to CI/CD *Binary package feeds for Yocto Project *Building container images with the Yocto Project Additional sessions and the full schedule covering a range of topics including devtool, best practices for building layers, working with/creating BSPs, can be found on the registration page. Register today. Pricing increases after September 27. REGISTER NOW > https://www.yoctoproject.org/yocto-project-summit-2019-2/ The Yocto Project Summit, scheduled for October 31-November 1, 2019 at the Lyon Convention Centre, Lyon, France, is a technical conference for engineers, open source technologists, students and academia in the OSS space. Organized in conjunction with ELCE 2019, this 2-day event is where individuals will learn about Yocto Projects' direction -- including, but not limited to, new releases, development tools, features -- get training on the next wave of embedded Linux technologies (segment previously known as Yocto Project Developer Day), and network with their industry peers, Yocto Project maintainers and experts. -- ___ yocto mailing list yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [thud] wget: Security fixes CVE-2018-20483
Source: http://git.savannah.gnu.org/cgit/wget.git/
Type: Security Fix
Disposition: Backport from http://git.savannah.gnu.org/cgit/wget.git/
Description:
Fixes CVE-2018-20483
Signed-off-by: Aviraj CJ
diff --git a/meta/recipes-extended/wget/wget/CVE-2018-20483_p1.patch
b/meta/recipes-extended/wget/wget/CVE-2018-20483_p1.patch
new file mode 100644
index 00..cbc4a127a8
--- /dev/null
+++ b/meta/recipes-extended/wget/wget/CVE-2018-20483_p1.patch
@@ -0,0 +1,73 @@
+From 6c5471e4834aebd7359d88b760b087136473bac8 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Tim=20R=C3=BChsen?=
+Date: Wed, 26 Dec 2018 13:51:48 +0100
+Subject: [PATCH 1/2] Don't use extended attributes (--xattr) by default
+
+* src/init.c (defaults): Set enable_xattr to false by default
+* src/main.c (print_help): Reverse option logic of --xattr
+* doc/wget.texi: Add description for --xattr
+
+Users may not be aware that the origin URL and Referer are saved
+including credentials, and possibly access tokens within
+the urls.
+
+CVE: CVE-2018-20483 patch 1
+Upstream-Status: Backport
[http://git.savannah.gnu.org/cgit/wget.git/commit/?id=c125d24762962d91050d925fbbd9e6f30b2302f8]
+Signed-off-by: Aviraj CJ
+---
+ doc/wget.texi | 8
+ src/init.c| 4
+ src/main.c| 2 +-
+ 3 files changed, 9 insertions(+), 5 deletions(-)
+
+diff --git a/doc/wget.texi b/doc/wget.texi
+index eaf6b380..3f9d7c1c 100644
+--- a/doc/wget.texi
b/doc/wget.texi
+@@ -540,6 +540,14 @@ right NUMBER.
+ Set preferred location for Metalink resources. This has effect if multiple
+ resources with same priority are available.
+
++@cindex xattr
++@item --xattr
++Enable use of file system's extended attributes to save the
++original URL and the Referer HTTP header value if used.
++
++Be aware that the URL might contain private information like
++access tokens or credentials.
++
+
+ @cindex force html
+ @item -F
+diff --git a/src/init.c b/src/init.c
+index eb81ab47..800970c5 100644
+--- a/src/init.c
b/src/init.c
+@@ -509,11 +509,7 @@ defaults (void)
+ opt.hsts = true;
+ #endif
+
+-#ifdef ENABLE_XATTR
+- opt.enable_xattr = true;
+-#else
+ opt.enable_xattr = false;
+-#endif
+ }
+
+ /* Return the user's home directory (strdup-ed), or NULL if none is
+diff --git a/src/main.c b/src/main.c
+index 81db9319..6ac1621b 100644
+--- a/src/main.c
b/src/main.c
+@@ -754,7 +754,7 @@ Download:\n"),
+ #endif
+ #ifdef ENABLE_XATTR
+ N_("\
+- --no-xattr turn off storage of metadata in extended
file attributes\n"),
++ --xattr turn on storage of metadata in extended
file attributes\n"),
+ #endif
+ "\n",
+
+--
+2.19.1
+
diff --git a/meta/recipes-extended/wget/wget/CVE-2018-20483_p2.patch
b/meta/recipes-extended/wget/wget/CVE-2018-20483_p2.patch
new file mode 100644
index 00..72ce8a0b33
--- /dev/null
+++ b/meta/recipes-extended/wget/wget/CVE-2018-20483_p2.patch
@@ -0,0 +1,127 @@
+From 5a4ee4f3c07cc5dc7ef5f7244fcf51fd2fa3bc67 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Tim=20R=C3=BChsen?=
+Date: Wed, 26 Dec 2018 14:38:18 +0100
+Subject: [PATCH 2/2] Don't save user/pw with --xattr
+
+Also the Referer info is reduced to scheme+host+port.
+
+* src/ftp.c (getftp): Change params of set_file_metadata()
+* src/http.c (gethttp): Change params of set_file_metadata()
+* src/xattr.c (set_file_metadata): Remove user/password from origin URL,
+ reduce Referer value to scheme/host/port.
+* src/xattr.h: Change prototype of set_file_metadata()
+
+CVE: CVE-2018-20483 patch 2
+Upstream-Status: Backport
[http://git.savannah.gnu.org/cgit/wget.git/commit/?id=3cdfb594cf75f11cdbb9702ac5e856c332ccacfa]
+Signed-off-by: Aviraj CJ
+---
+ src/ftp.c | 2 +-
+ src/http.c | 4 ++--
+ src/xattr.c | 24
+ src/xattr.h | 3 ++-
+ 4 files changed, 25 insertions(+), 8 deletions(-)
+
+diff --git a/src/ftp.c b/src/ftp.c
+index 69148936..db8a6267 100644
+--- a/src/ftp.c
b/src/ftp.c
+@@ -1580,7 +1580,7 @@ Error in server response, closing control
connection.\n"));
+
+ #ifdef ENABLE_XATTR
+ if (opt.enable_xattr)
+-set_file_metadata (u->url, NULL, fp);
++set_file_metadata (u, NULL, fp);
+ #endif
+
+ fd_close (local_sock);
+diff --git a/src/http.c b/src/http.c
+index 77bdbbed..472c328f 100644
+--- a/src/http.c
b/src/http.c
+@@ -4120,9 +4120,9 @@ gethttp (const struct url *u, struct url *original_url,
struct http_stat *hs,
+ if (opt.enable_xattr)
+ {
+ if (original_url != u)
+-set_file_metadata (u->url, original_url->url, fp);
++set_file_metadata (u, original_url, fp);
+ else
+-set_file_metadata (u->url, NULL, fp);
++set_file_metadata (u, NULL, fp);
+ }
+ #endif
+
+diff --git a/src/xattr.c b/src/xattr.c
+index 66524226..0f20fadf 100644
+--- a/src/xattr.c
b/src/xattr.c
+@@ -21,6 +21,7 @@
+ #include
+
+ #include "log.h"
++#include "utils.h"
+ #include "xattr.h"
+
+ #ifdef USE_XATTR
+@@ -57,7 +58,7 @@ write_xattr_metadata (const
[OE-core] (no subject)
All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too. Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 309 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, “2.8”, “2.9’, "2.99" and "Future", the more pressing/urgent issues being in "2.8" and then “2.9”. Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp...@gmail.com) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs -- Thanks, *Stephen K. Jolley* *Yocto Project Program Manager* *7867 SW Bayberry Dr., Beaverton, OR 97007* (*Cell*:(208) 244-4460 * *Email*: *s jolley.yp...@gmail.com * -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Xilinx/meta-jupyter layer
On 9/27/19 3:12 PM, Chandana Kalluri wrote: > Hello all, > > https://github.com/Xilinx/meta-jupyter is a meta-jupyter layer containing > recipes for jupyter notebook. The initial recipes are based of Dmitry > Kargin's meta-jupyter layer > https://layers.openembedded.org/layerindex/branch/master/layer/meta-jupyter/. > This layer has not been updated for a while. > > The Xilinx/meta-jupyter layer also adds recipes for python3 based notebooks > apart from existing python2 based notebooks. > This layer has been tested using Yocto thud layer and by running jupyter > notebooks on Ultra96 community boards. > We would like to maintain Xilinx/meta-jupyter layer actively and welcome > contributions to this layer either through pull requests or via patches sent > to meta-xilinx mailing list until a mailing list for meta-jupyter is in > place. In the next cycle we will deprecate python2 recipes. > > A question to community, > - Would you recommend maintaining this layer separately in the current > github.com/Xilinx location or be included under meta- openembedded layers. > - Would you suggest having a separate mailing list ? I'd suggest that you should consider either keeping it on github, or offering it to the git.yoctoproject.org. I can assist with this if you need. Since this is pretty targeted to a specific use-case, either would make sense to me. --Mark > Thanks, > Chandana > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] bluez5: Fix for --enable-btpclient
On 29/09/2019 04:44, Robert Yang wrote: +Upstream-Status: Inappropriate [Upstream already fixed] So this is a backport then? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] ruby: fix non-IPv6 support
On Fri, 2019-09-27 at 17:32 +0200, Alexander Kanavin wrote: > On Fri, 27 Sep 2019 at 17:24, André Draszik wrote: > > Can't the auto-updater do it? (Without the repackaging?) > > I think it fails at the rebasing patches step - merge conflicts can only be > resolved by a human. OK, I'll try to have a look anyway... A. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] ruby: configure mis-detects isnan/isinf on musl
On Fri, 2019-09-27 at 16:15 +0100, Ross Burton wrote: > On 27/09/2019 14:54, André Draszik wrote: > > From: André Draszik > > > > The configure script does not detect isnan/isinf as macros > > as is the case in musl. > > > > Help it by providing the correct result via > > CACHED_CONFIGUREVARS. > > Is this reported as a bug upstream so we can remove this workaround at > some point? Now that you say it - actually somebody else did before, and they've also fixed it in later versions. New patch coming. A. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
