Hello, with the deprecation of SERIAL_CONSOLE the following was introduced in bitbake.conf: 3f0d665384e6d1b7aa2854a9cc4f13e0961bacb7 (bitbake.conf: set SERIAL_CONSOLES from SERIAL_CONSOLE by

Hello, I'm already carrying this upgrade from Khem, earlier today. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

Hi Jose, Am 4/11/2022 um 3:30 PM schrieb Jose Quaresma: Yes... of course this is wrong. /lib/ld-linux-x86-64.so.2 is the default linker path for yocto on x86_64 Sorry about that Joerg

J?rg Vehlow <lkml@...> escreveu no dia segunda, 11/04/2022 à(s) 13:35: Is this correct? The first path is the seme one of the second. Jose -- Best regards, José Quaresma

This release contains security fixes including CVE-2022-26280 fix. Signed-off-by: Davide Gardenal <davide.gardenal@...> --- Update v3: Instead of backporting the patch upgrade to the

Hi Quentin, I just missed the release so I'm going to send a v3 patch now, thanks!

Hi Davide, Any reason for not updating to 3.6.1 since it includes this patch (from the changelog info at least)? Cheers, Quentin

Signed-off-by: Davide Gardenal <davide.gardenal@...> --- Update v2: Change title from [meta-oe] to [oe-core] --- .../libarchive/CVE-2022-26280.patch | 31 +++++++++++++++++++

Signed-off-by: Davide Gardenal <davide.gardenal@...> --- .../libarchive/CVE-2022-26280.patch | 31 +++++++++++++++++++ .../libarchive/libarchive_3.6.0.bb | 4 ++- 2 files

From: Joerg Vehlow <joerg.vehlow@...> When gos internal linker is used, it uses hardcoded paths to the interpreter (dynamic linker). For x86_64 this hardcoded path is /lib64/ld-linux-x86-64.so.2,

Signed-off-by: Alexander Kanavin <alex@...> --- meta/recipes-support/itstool/itstool_2.0.7.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git

Am 08.04.2022 um 22:03 schrieb Markus Volk via lists.openembedded.org: Regarding the documentation the ReadOnlyPaths and ReadWritePaths makes not sense because ProtectSystem=full mounts /usr, boot

It's the dependencies that you have to count as well in order to link with libgnutls in a program. libgnutls requires nettle which requires GMP. GMP (>= 6.0.0) is dual licensed LGPLv3+ or GPLv2+.

The build shows below error while building for arm machines. Exception: TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType' Detailed error info : Steps to

Am 11.04.22 um 06:25 schrieb Andre McCurdy: In a perfect world, I would say you are right. There should not even exist more than one implementation. In reality, at least for

This actually are just 2 patches on top of what we have thus far * 7a43f6fe release 1.2.3 * 01b14242 accept null pointer as message argument to gettext functions Signed-off-by: Khem Raj

This should either be gnutls or openssl, not both. But aside from that, gnutls brings (L)GPLv3 issues and therefore should not be enabled by default. Are you saying that some glib-networking

Changes in this release [1] [1] https://github.com/GNOME/pango/commit/37a427018c92a2bc679ef104097e07a619609c9c Signed-off-by: Khem Raj <raj.khem@...> --- v2: Rebased

Changes in this release [1] [1] https://github.com/libarchive/libarchive/releases/tag/v3.6.1 Signed-off-by: Khem Raj <raj.khem@...> --- v2: Fix subject line to reflect right version

Hi Markus, Please use one commit per component as it is easy to describe. Jose Markus Volk <f_l_k@...> escreveu no dia domingo, 10/04/2022 à(s) 18:29: -- Best regards, José Quaresma