[OE-core] [PATCH] base-passwd: LICENSE changed to GPLv2

Signed-off-by: Wang Mingyu --- meta/recipes-core/base-passwd/base-passwd_3.5.29.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb index d1aab09181..d01cd7e297 100644 ---

Re: [OE-core] [PATCH 2/2] parselogs.py: whitelist more xserver related error

On 3/11/20 4:26 PM, Richard Purdie wrote: On Wed, 2020-03-11 at 10:13 +0800, changqing...@windriver.com wrote: From: Changqing Li With default config, these errors always exist for core-image-sato, and xserver-nodm.server start successfully, these errors are not critially. If set default sy

[OE-core] [PATCH 2/2] binutils: fix CVE-2020-0551

Signed-off-by: Anuj Mittal --- .../binutils/binutils-2.34.inc| 1 + .../binutils/binutils/CVE-2020-0551.patch | 549 ++ 2 files changed, 550 insertions(+) create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2020-0551.patch diff --git a/meta/recip

[OE-core] [PATCH 1/2] bluez: fix CVE-2020-0556

It was discovered that BlueZ's HID and HOGP profiles implementations don't specifically require bonding between the device and the host. This creates an opportunity for an malicious device to connect to a target host to either impersonate an existing HID device without security or to cause an SDP

[OE-core] [PATCH] gcc: Upgrade to 9.3 bugfix release

This brings ~157 bugfixes [1] to gcc-9 with no features Drop backports which are already part of the release now [1] https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&list_id=260610&resolution=FIXED&target_milestone=9.3 Signed-off-by: Khem Raj --- meta/conf/distro/include/maintainer

[OE-core] [PATCH] weston-init: Launch weston with WESTON_DISABLE_ATOMIC on musl/x86

Since we enabled drm/kms backend for qemux86, it does not work with musl fdbdev worked ok, we see this error [18:58:45.628] launching '/usr/libexec/weston-desktop-shell' [18:58:45.737] atomic: couldn't commit new state: Invalid argument [18:58:45.737] repaint-flush failed: Invalid argument There

[OE-core] [PATCH] musl: removes aliases for glibc provided libraries

From: Jan Kaisrlik Based on the recommendation in musl mailing list[1] All symlinks have been removed from musl recipe. [1]: https://www.openwall.com/lists/musl/2020/03/10/11 Signed-off-by: Jan Kaisrlik Signed-off-by: Khem Raj --- meta/recipes-core/musl/musl_git.bb | 15 +-- 1 fi

[OE-core] [PATCH] scripts/oe-buildenv-internal: Add BB_LOGCONFIG

We should allow the logging configurations to be specificed from the environment, for example for autobuilder setups. Signed-off-by: Richard Purdie --- scripts/oe-buildenv-internal | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/oe-buildenv-internal b/scripts/oe-bui

Re: [OE-core] [PATCH] qemu: fix CVE-2020-7039

On 3/12/20 1:53 PM, Randy MacLeod wrote: > On 2020-02-27 12:25 a.m., changqing...@windriver.com wrote: >> From: Changqing Li got it fixed up. its sitting @ http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akuster/master-next_qemu_fix I will through it at the AB so will let RP deci

Re: [OE-core] [PATCH] qemu: fix CVE-2020-7039

Randy, On 3/12/20 1:53 PM, Randy MacLeod wrote: > On 2020-02-27 12:25 a.m., changqing...@windriver.com wrote: >> From: Changqing Li This does not apply cleanly to current master.  it needs to be rebased ( suspect qemu: update Xen packages names for the xen-tools recipe). Do know if it is in con

Re: [OE-core] [PATCH 05/13] weston-init: use the drm/kms backend rather than fbdev one for qemux86 machines

On Wed, Feb 19, 2020 at 11:49 AM Alexander Kanavin wrote: > > The fbdev backend is not documented, and not the default; > as the emulated hardware in qemu now supports DRM/KMS > (both std and virtio), we should align with upstream default > and vast majority of users. Empty init file will cause >

Re: [OE-core] [PATCH] qemu: fix CVE-2020-7039

On 2020-02-27 12:25 a.m., changqing...@windriver.com wrote: From: Changqing Li Signed-off-by: Changqing Li --- meta/recipes-devtools/qemu/qemu.inc| 3 + .../qemu/qemu/CVE-2020-7039-1.patch| 44 +++ .../qemu/qemu/CVE-2020-7039-2.patch

Re: [OE-core] runqemu nographic and hvc0

On Thu, Mar 12, 2020 at 9:44 AM Andre McCurdy wrote: > > On Thu, Mar 12, 2020 at 9:13 AM Khem Raj wrote: > > On 3/12/20 8:21 AM, Marko, Peter wrote: > > > Hi, > > > > > > I'm trying to boot my own qemu image on zeus branch with "runqemu > > > nographic /path/to/extracted/rootfs" but I have probl

Re: [OE-core] [PATCH] netbase: use snapshot.debian.org

On Thu, Mar 12, 2020 at 9:25 AM Alexander Kanavin wrote: > > On Thu, 12 Mar 2020 at 17:08, Khem Raj wrote: >> >> > This will break version checks and automated upgrades. Is it possible to >> > build from git instead? >> > Specifically: https://salsa.debian.org/md/netbase >> >> That repo is debian

Re: [OE-core] simplest command to display which layers are applying the same patch?

On Thu, Mar 12, 2020 at 7:30 AM wrote: > Quoting Alexander Kanavin : > > > I think 'bitbake -e recipe', and then searching for SRC_URI in it should > > show which layer applies which patch. > >... snip ... > > I *think* I know what might be happening here, and I'd like to verify > some suspici

Re: [OE-core] runqemu nographic and hvc0

On Thu, Mar 12, 2020 at 9:13 AM Khem Raj wrote: > On 3/12/20 8:21 AM, Marko, Peter wrote: > > Hi, > > > > I'm trying to boot my own qemu image on zeus branch with "runqemu nographic > > /path/to/extracted/rootfs" but I have problem that console is flooded with > > process '/sbin/getty 115200 hvc0

Re: [OE-core] [PATCH] netbase: use snapshot.debian.org

On Thu, 12 Mar 2020 at 17:08, Khem Raj wrote: > > This will break version checks and automated upgrades. Is it possible to > > build from git instead? > > Specifically: https://salsa.debian.org/md/netbase > > That repo is debian build metadata sources for netbase. > Nope. It is the actual source

Re: [OE-core] runqemu nographic and hvc0

On 3/12/20 8:21 AM, Marko, Peter wrote: Hi, I'm trying to boot my own qemu image on zeus branch with "runqemu nographic /path/to/extracted/rootfs" but I have problem that console is flooded with process '/sbin/getty 115200 hvc0' (pid 383) exited. Scheduling for restart. starting pid 385, tty

Re: [OE-core] [PATCH] netbase: use snapshot.debian.org

On 3/12/20 1:25 AM, Alexander Kanavin wrote: On Thu, 12 Mar 2020 at 04:22, > wrote: -SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz" +SRC_URI = "http://snapshot.debian.org/archive/debian/20200311T090704Z/pool/main/n/${BPN}/${BPN}_${P

[OE-core] runqemu nographic and hvc0

Hi, I'm trying to boot my own qemu image on zeus branch with "runqemu nographic /path/to/extracted/rootfs" but I have problem that console is flooded with process '/sbin/getty 115200 hvc0' (pid 383) exited. Scheduling for restart. starting pid 385, tty '': '/sbin/getty 115200 hvc0' I'm using yoct

[OE-core] [PATCH] libsdl2: upgrade 2.0.10 -> 2.0.12

* checked all hunks: backported patches can go * for machines with neon in TUNE_FEATURES enable new configure option --enable-arm-neon. If enabled, license must be extended to MIT * license checksum changed by copyright year Signed-off-by: Andreas Müller --- ...alidate-image-size-when-loading-

Re: [OE-core] simplest command to display which layers are applying the same patch?

Hi, On Thu, Mar 12, 2020 at 10:30:03AM -0400, rpj...@crashcourse.ca wrote: > > Quoting Alexander Kanavin : > > > I think 'bitbake -e recipe', and then searching for SRC_URI in it should > > show which layer applies which patch. > > ... snip ... > > I *think* I know what might be happening he

Re: [OE-core] [PATCH 1/2] babletrace2: make manpages multilib identical

Maybe. They may want it to be altered depending on their preference for how to express the system libdir. I have pushed similar to other projects and gotten a mixed bag of responses. I haven't tried to push it yet, but its in my queue. On 3/12/2020 7:25 AM, Jonathan Rajotte-Julien wrote: Hi I

Re: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433

I looked for dependent packages in oe-core and in meta-oe with grep and found only enchant and enchant2 although I was able to build both of them having the aspell patch applied. Best regards, Stefan Ghinea On 3/12/20 14:25, Mittal, Anuj wrote: It looks like this is changing the API. I wonder

Re: [OE-core] [PATCH] babeltrace2: initialize the other_entry pointer

Hi Mingli, Thanks for also posting this on the lttng-dev mailing list. I'm sure we can get this in fairly quickly upstream. This is more a question for Richard and other core members of oe, is this kind of patch pertinent for upstream oe considering it is only silencing a warning (based on [1])?

Re: [OE-core] simplest command to display which layers are applying the same patch?

Quoting Alexander Kanavin : I think 'bitbake -e recipe', and then searching for SRC_URI in it should show which layer applies which patch. ... snip ... I *think* I know what might be happening here, and I'd like to verify some suspicions about how recipes are selected and patches are appl

Re: [OE-core] [PATCH 1/2] babletrace2: make manpages multilib identical

Hi Is this something upstream (lttng-dev mailing list) should be interested in? Cheers On Wed, Mar 11, 2020 at 03:22:48PM -0700, Jeremy A. Puhlman wrote: > From: Jeremy Puhlman > > Signed-off-by: Jeremy A. Puhlman > --- > .../0001-Make-manpages-multilib-identical.patch| 28 > +++

Re: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433

Yes, you are correct. White listing isn't right either. -Mikko -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] simplest command to display which layers are applying the same patch?

Ah, I was just playing with a build of my own (which works so I can't replicate the error), but if I "bitbake -e openssl", then I can obviously see all the operations that go into constructing the SRC_URI, along with the layers that contribute to that expansion, so I am assuming that, even if more

Re: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433

> -Original Message- > From: mikko.rap...@bmw.de > Sent: Thursday, March 12, 2020 08:34 PM > To: Mittal, Anuj > Cc: openembedded-core@lists.openembedded.org; stefan.ghi...@windriver.com > Subject: Re: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433 > > On Thu, Mar 12, 2020 at 12:25:21

Re: [OE-core] simplest command to display which layers are applying the same patch?

I think 'bitbake -e recipe', and then searching for SRC_URI in it should show which layer applies which patch. Alex On Thu, 12 Mar 2020 at 13:56, wrote: >just got from colleague a miniscule snippet of build output: > > ERROR: openssl-1.0.2u-r0 do_patch: Command Error: 'quilt --quiltrc ... >

[OE-core] simplest command to display which layers are applying the same patch?

just got from colleague a miniscule snippet of build output: ERROR: openssl-1.0.2u-r0 do_patch: Command Error: 'quilt --quiltrc ... snip ... Output: Patch Use-SHA256-not-MD5-as-default-digest.patch is already applied; check your series file the problem seems obvious ... more than one laye

Re: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433

On Thu, Mar 12, 2020 at 12:34:19PM +, mikko.rap...@bmw.de wrote: > On Thu, Mar 12, 2020 at 12:25:21PM +, Mittal, Anuj wrote: > > It looks like this is changing the API. I wonder if this would need any > > other change or break something elsewhere in OE-core, meta-oe? > > > > http://aspell.

Re: [OE-core] CVE related consulting on linux-yocto on zeus branch

On Thu, Mar 12, 2020 at 2:28 AM zangrc wrote: > > Our team plans to submit CVE-related patches that are not included in > -stable, but we found that the current version of the linux-yocto recipe > is lower than the linux-yocto git repository. On which version should we > make the patch. Send patc

Re: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433

On Thu, Mar 12, 2020 at 12:25:21PM +, Mittal, Anuj wrote: > It looks like this is changing the API. I wonder if this would need any > other change or break something elsewhere in OE-core, meta-oe? > > http://aspell.net/buffer-overread-ucs.txt Debian classified issues as minor and fixed only b

Re: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433

It looks like this is changing the API. I wonder if this would need any other change or break something elsewhere in OE-core, meta-oe? http://aspell.net/buffer-overread-ucs.txt Thanks, Anuj On Thu, 2020-03-12 at 11:23 +0200, Stefan Ghinea wrote: > libaspell.a in GNU Aspell before 0.60.8 has a b

[OE-core] [PATCH] [zeus] aspell: CVE-2019-20433

libaspell.a in GNU Aspell before 0.60.8 has a buffer over-read for a string ending with a single '\0' byte, if the encoding is set to ucs-2 or ucs-4 outside of the application, as demonstrated by the ASPELL_CONF environment variable. References: https://nvd.nist.gov/vuln/detail/CVE-2019-20433 Ups

Re: [OE-core] [PATCH] oeqa: enable testresults.json for testexport

On Wed, 2020-03-11 at 17:37 +0100, Stefan Kral wrote: > Add the option --json-result-dir to oeqa core context to enable > testresults.json creation for test runs via testexport. > > Eg. oe-test runtime --json-result-dir . > > Signed-off-by: Stefan Kral > --- > meta/lib/oeqa/core/context.py | 30

Re: [OE-core] psplash activation state w/ systemd

On Wed, Mar 11, 2020 at 5:27 PM Alex Kiernan wrote: > > On Wed, Mar 11, 2020 at 5:20 PM Richard Purdie > wrote: > > > > On Mon, 2020-03-09 at 15:18 +, Alex Kiernan wrote: > > > I've a branch with systemd 245 on it which fails testing because > > > psplash gets restarted all the time. > > > >

Re: [OE-core] [PATCH] netbase: use snapshot.debian.org

On Thu, 12 Mar 2020 at 04:22, wrote: > -SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz" > +SRC_URI = " > http://snapshot.debian.org/archive/debian/20200311T090704Z/pool/main/n/${BPN}/${BPN}_${PV}.tar.xz > " > This will break version checks and automated upgrades. Is it possible to

Re: [OE-core] [PATCH] oeqa: enable testresults.json for testexport

On Wed, 11 Mar 2020 at 22:27, Stefan Kral wrote: > Doing build and test in one pipeline turns out to be more complicated due > to: > > - build machine may be different from test machine (with access to > hardware) > - build the image is a one time job, tests may have to be repeated > reproducibly

[OE-core] [PATCH] oeqa/qemuarm64: Ignore logind: failed to get session seat

When booting weston images this error is seen commonly, but Qemu boots the image fine, session seat error is thrown by libweston perhaps using --seat option or setting XDG_SEAT variable in weston.ini could fix it [YOCTO #13828] Signed-off-by: Khem Raj --- meta/lib/oeqa/runtime/cases/parselogs.p