Date   

[meta-zephyr][PATCH v2 0/4] Fix efi generation and add x86 MACHINE confs (cover letter)

Naveen Saini
 

(1) zephyr-kernel-src: fix efi generation failure for x86 boards

With zephyr v2.5.0, EFI binary generation support has been added for x86 board (64-bit mode).
To achieve this, an python tool[1] has been added to convert zephyr EFL file
into an EFI appliable. But unfortunately at current this does not work with Yocto cross-compilation env.
This patch fix this issue and allow to build zephyr.efi for ehl_crb and up_squared boards.


(2)
Instead of creating machine configuration for each
supported boards, I would like to have common machine configurations for
supported boards. One for 64-bit (intel-x86-64.conf) and one for 32-bit
(intel-x86-32.conf).

User need to specify board value to ZEPHYR_BOARD in local.conf based on
targeted board i.e
ZEPHYR_BOARD = "ehl_crb"

64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb (default)
* acrn
* acrn_ehl_crb

32-bit supported boards:
* up_squared_32
* minnowboard (default)

(3) Dropped acrn MACHINE configuration, which can be build with
MACHINE = "intel-x86-64"
ZEPHYR_BOARD = "acrn"

---
v2:
Fixed build for Zephyr 2.4.0
Dropped ACRN configuration

Naveen Saini (4):
zephyr-kernel-src: fix efi generation failure for x86 boards
intel-x86-64.conf: add common MACHINE for x86 (64-bit) BOARDS
intel-x86-32.conf: add common MACHINE for x86 (32-bit) BOARDS
acrn.conf: drop acrn machine configuration

conf/machine/acrn.conf | 9 ---
conf/machine/include/tune-core2-common.inc | 6 ++
conf/machine/include/tune-corei7-common.inc | 3 +
conf/machine/intel-x86-32.conf | 12 +++
conf/machine/intel-x86-64.conf | 14 ++++
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 3 +
.../zephyr-kernel/zephyr-kernel-src.inc | 8 +-
8 files changed, 122 insertions(+), 13 deletions(-)
delete mode 100644 conf/machine/acrn.conf
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf
create mode 100644 conf/machine/intel-x86-64.conf
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

--
2.17.1


Re: hostile freenode takeover

Philip Balister
 

On 5/20/21 4:32 AM, Nicolas Dechesne wrote:
On Thu, May 20, 2021 at 10:16 AM Quentin Schulz <
quentin.schulz@streamunlimited.com> wrote:

Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:
On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:



On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <
Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

Thanks for your email. We are aware, and have started to look into
that.

It looks like some open source communities have started to move to
https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring
any insights or recommendations... feel free!

perhaps good time to consider matrix
I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.
I think the question of setting up Matrix for our community is a valid
question, though I think it's orthogonal to the current problem. If
freenode goes away , we need an alternate plan to move *right away* to
another IRC server. If we want to setup addition communications means (such
as Matrix or anything else) that needs to be discussed and it might take
more time.
We have registered #oe and #yocto on libera already, so we can easily
transition irc servers as the situation develops.

Philip




Cheers,
Quentin




Re: hostile freenode takeover

Yocto
 


On 5/20/21 3:32 PM, Nicolas Dechesne wrote:


On Thu, May 20, 2021 at 10:16 AM Quentin Schulz <quentin.schulz@...> wrote:
Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:
> On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
> <nicolas.dechesne@...> wrote:
> >
> >
> >
> > On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@...> wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >>
> >> Dear all,
> >>
> >> there have been recent reports of a hostile takeover of the freenode
> >> service, as described in
> >> https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
> >>
> >> The Yocto Project should verify these reports and take the necessary
> >> actions, in order to protect its users.
> >
> >
> > Thanks for your email. We are aware, and have started to look into that.
> >
> > It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free!
>
> perhaps good time to consider matrix
>

I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.

I think the question of setting up Matrix for our community is a valid question, though I think it's orthogonal to the current problem. If freenode goes away , we need an alternate plan to move *right away* to another IRC server. If we want to setup addition communications means (such as Matrix or anything else) that needs to be discussed and it might take more time.

First let me say, there is nothing wrong with matrix, have used it every day for years

Second

the discussion is now about libre


there's a relay to relay stuff between libera and freenode?!
magic
LiberaRelay (relay@2607:f5a0:0:7::9) has joined #hardenedbsd
[Libera] R​elay (relay@user/relay) has joined #hardenedbsd
xmj: sup ? Libra?? whats dat ?
new irc net, made by freenode staffers that have been booted
freenode went through a hostile takeover
... in case you haven't noticed ;p

https://kline.sh/


 

Cheers,
Quentin




Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.3.1.rc1)

Sangeeta Jain
 

Hello All,

This is the full report for yocto-3.3.1.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

No new issue found.


Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Pokybuild User
Sent: Monday, 17 May, 2021 9:47 PM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.3.1.rc1)


A build flagged for QA (yocto-3.3.1.rc1) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.3.1.rc1


Build hash information:

bitbake: b67476d4758915db7a5d9f58bc903ae7501a1774
meta-arm: 7ca13b4f15cc8f51d6c99b40b7ffafeb47dce28e
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 4d5791d9ff515ba1660234b1987eae4d4e90eeca
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
oecore: efce6334bf122a64f63d46c1c04e3dbffe298c51
poky: 05a8aad57ce250b124db16705acec557819905ae



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org







Re: hostile freenode takeover

Nicolas Dechesne
 



On Thu, May 20, 2021 at 10:16 AM Quentin Schulz <quentin.schulz@...> wrote:
Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:
> On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
> <nicolas.dechesne@...> wrote:
> >
> >
> >
> > On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@...> wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >>
> >> Dear all,
> >>
> >> there have been recent reports of a hostile takeover of the freenode
> >> service, as described in
> >> https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
> >>
> >> The Yocto Project should verify these reports and take the necessary
> >> actions, in order to protect its users.
> >
> >
> > Thanks for your email. We are aware, and have started to look into that.
> >
> > It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free!
>
> perhaps good time to consider matrix
>

I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.

I think the question of setting up Matrix for our community is a valid question, though I think it's orthogonal to the current problem. If freenode goes away , we need an alternate plan to move *right away* to another IRC server. If we want to setup addition communications means (such as Matrix or anything else) that needs to be discussed and it might take more time. 
 

Cheers,
Quentin


Re: hostile freenode takeover

Quentin Schulz
 

Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:
On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:



On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

Thanks for your email. We are aware, and have started to look into that.

It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free!
perhaps good time to consider matrix
I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.

Cheers,
Quentin


Re: [meta-zephyr][PATCH] qemuzephyrrunner.py: use existing qemu conf file

Naveen Saini
 

Hi Jon,

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On
Behalf Of Jon Mason
Sent: Tuesday, May 18, 2021 11:10 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] [meta-zephyr][PATCH] qemuzephyrrunner.py: use existing
qemu conf file

Read the generated QEMU conf file, instead of using hard coded values.
This allows for machines not conforming to the hard coded values to work
with testimage.

Signed-off-by: Jon Mason <jon.mason@arm.com>
---
conf/machine/qemu-x86.conf | 1 +
lib/oeqa/utils/qemuzephyrrunner.py | 89 +++++++++++++++++++++++++--
---
2 files changed, 77 insertions(+), 13 deletions(-)

diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf
index d85c22215520..ce79b5b1f510 100644
--- a/conf/machine/qemu-x86.conf
+++ b/conf/machine/qemu-x86.conf
@@ -9,6 +9,7 @@ ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"

# For runqemu
QB_SYSTEM_NAME = "qemu-system-i386"
+QB_MACHINE = "-machine type=pc-1.3"
[Naveen] ruqemu failed with qemu-x86 machine
runqemu - ERROR - Failed to run qemu: qemu-system-i386: -nographic: unsupported machine type

I run in my host :
$ qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-i386 -machine help

Supported machines are:
microvm microvm (i386)
pc Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-6.0)
pc-i440fx-6.0 Standard PC (i440FX + PIIX, 1996) (default)
pc-i440fx-5.2 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-5.1 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-5.0 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-4.2 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-4.1 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-4.0 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-3.1 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-3.0 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.9 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.8 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.7 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.6 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.5 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.4 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.3 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.2 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.12 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.11 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.10 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.1 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.0 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.7 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.6 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.5 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.4 Standard PC (i440FX + PIIX, 1996)
q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-6.0)
pc-q35-6.0 Standard PC (Q35 + ICH9, 2009)
pc-q35-5.2 Standard PC (Q35 + ICH9, 2009)
pc-q35-5.1 Standard PC (Q35 + ICH9, 2009)
pc-q35-5.0 Standard PC (Q35 + ICH9, 2009)
pc-q35-4.2 Standard PC (Q35 + ICH9, 2009)
pc-q35-4.1 Standard PC (Q35 + ICH9, 2009)
pc-q35-4.0.1 Standard PC (Q35 + ICH9, 2009)
pc-q35-4.0 Standard PC (Q35 + ICH9, 2009)
pc-q35-3.1 Standard PC (Q35 + ICH9, 2009)
pc-q35-3.0 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.9 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.8 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.7 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.6 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.5 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.4 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.12 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.11 Standard PC (Q35 + ICH9, 2009)
pc-q35-2.10 Standard PC (Q35 + ICH9, 2009)
isapc ISA-only PC
none empty machine
x-remote Experimental remote machine



QB_OPT_APPEND = "-nographic -no-acpi"
QB_CPU_x86 = "-cpu qemu32,+nx,+pae"
QB_CPU_KVM_x86 = "-cpu kvm32"
diff --git a/lib/oeqa/utils/qemuzephyrrunner.py
b/lib/oeqa/utils/qemuzephyrrunner.py
index e8a1bd4544cf..a1ed30be1ca8 100644
--- a/lib/oeqa/utils/qemuzephyrrunner.py
+++ b/lib/oeqa/utils/qemuzephyrrunner.py
@@ -14,6 +14,7 @@ import select
import bb
import tempfile
import sys
+import configparser
from oeqa.utils.qemurunner import QemuRunner

class QemuZephyrRunner(QemuRunner):
@@ -42,6 +43,72 @@ class QemuZephyrRunner(QemuRunner):
# 5 minutes timeout...
self.endtime = time.time() + 60*5

+ self.qemuboot = False
+ self.d = {'QB_KERNEL_ROOT': '/dev/vda'}
+
+ def get(self, key):
+ if key in self.d:
+ return self.d.get(key)
+ elif os.getenv(key):
+ return os.getenv(key)
+ else:
+ return ''
+
+ def set(self, key, value):
+ self.d[key] = value
+
+ def read_qemuboot(self):
+ if not self.qemuboot:
+ if self.get('DEPLOY_DIR_IMAGE'):
+ deploy_dir_image = self.get('DEPLOY_DIR_IMAGE')
+ else:
+ bb.warning("Can't find qemuboot conf file, DEPLOY_DIR_IMAGE is
NULL!")
+ return
+
+ if self.rootfs and not os.path.exists(self.rootfs):
+ # Lazy rootfs
+ machine = self.get('MACHINE')
+ if not machine:
+ machine = os.path.basename(deploy_dir_image)
+ self.qemuboot = "%s/%s-%s.qemuboot.conf" %
(deploy_dir_image,
+ self.rootfs, machine)
+ else:
+ cmd = 'ls -t %s/*.qemuboot.conf' % deploy_dir_image
+ try:
+ qbs = subprocess.check_output(cmd, shell=True).decode('utf-8')
+ except subprocess.CalledProcessError as err:
+ raise RunQemuError(err)
+ if qbs:
+ for qb in qbs.split():
+ # Don't use initramfs when other choices unless fstype is ramfs
+ if '-initramfs-' in os.path.basename(qb) and self.fstype !=
'cpio.gz':
+ continue
+ self.qemuboot = qb
+ break
+ if not self.qemuboot:
+ # Use the first one when no choice
+ self.qemuboot = qbs.split()[0]
+ self.qbconfload = True
+
+ if not self.qemuboot:
+ # If we haven't found a .qemuboot.conf at this point it probably
+ # doesn't exist, continue without
+ return
+
+ if not os.path.exists(self.qemuboot):
+ raise RunQemuError("Failed to find %s (wrong image name or
+ BSP does not support running under qemu?)." % self.qemuboot)
+
+ cf = configparser.ConfigParser()
+ cf.read(self.qemuboot)
+ for k, v in cf.items('config_bsp'):
+ k_upper = k.upper()
+ if v.startswith("../"):
+ v = os.path.abspath(os.path.dirname(self.qemuboot) + "/" + v)
+ elif v == ".":
+ v = os.path.dirname(self.qemuboot)
+ self.set(k_upper, v)
+
+
def create_socket(self):
bb.note("waiting at most %s seconds for qemu pid" %
self.runqemutime)
tries = self.runqemutime
@@ -66,7 +133,6 @@ class QemuZephyrRunner(QemuRunner):

if not os.path.exists(self.tmpdir):
bb.error("Invalid TMPDIR path %s" % self.tmpdir)
- #logger.error("Invalid TMPDIR path %s" % self.tmpdir)
return False
else:
os.environ["OE_TMPDIR"] = self.tmpdir @@ -82,21 +148,18 @@ class
QemuZephyrRunner(QemuRunner):
bb.error("Invalid kernel path: %s" % self.kernel)
return False

- self.qemuparams = '-nographic -serial unix:%s,server' %
(self.socketname)
- qemu_binary = ""
- if 'arm' in self.machine or 'cortex' in self.machine:
- qemu_binary = 'qemu-system-arm'
- qemu_machine_args = '-machine lm3s6965evb'
- elif 'x86' in self.machine:
- qemu_binary = 'qemu-system-i386'
- qemu_machine_args = '-machine type=pc-1.3 -no-acpi -nographic -
cpu qemu32,+nx,+pae'
- elif 'nios2' in self.machine:
- qemu_binary = 'qemu-system-nios2'
- qemu_machine_args = '-machine altera_10m50_zephyr'
- else:
+ self.qemuparams = '-serial unix:%s,server' % (self.socketname)
+
+ self.read_qemuboot()
+ qemu_binary = self.get('QB_SYSTEM_NAME')
+ qemu_machine_args = self.get('QB_MACHINE')
+ if qemu_binary == "" or qemu_machine_args == "":
bb.error("Unsupported QEMU: %s" % self.machine)
return False

+ self.qemuparams += " %s " %self.get('QB_OPT_APPEND')
+ self.qemuparams += " %s " %self.get('QB_CPU')
+
self.origchldhandler = signal.getsignal(signal.SIGCHLD)
signal.signal(signal.SIGCHLD, self.handleSIGCHLD)

--
2.20.1


[meta-dpdk][PATCH] dpdk: fix build with GCC 11

Yu, Mingli
 

From: Mingli Yu <mingli.yu@windriver.com>

Fixes:
| In function 'memset',
| inlined from 'test_table_stub' at test_table_tables.c:151:4:
| /buildarea/tmp/work/intel_x86_64-wrs-linux/dpdk/19.11.5-r0/recipe-sysroot/usr/include/bits/string_fortified.h:59:10: error: '__builtin_memset' offset [0, 31] is out of the bounds [0, 0] [-Werror=array-bounds]

Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
...001-test-table-fix-build-with-GCC-11.patch | 56 +++++++++++++++++++
recipes-extended/dpdk/dpdk_19.11.5.bb | 3 +-
2 files changed, 58 insertions(+), 1 deletion(-)
create mode 100644 recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-11.patch

diff --git a/recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-11.patch b/recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-11.patch
new file mode 100644
index 0000000..4f76290
--- /dev/null
+++ b/recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-11.patch
@@ -0,0 +1,56 @@
+From 33c12ac5ba5f09727c6de807e71403dd260a7bbc Mon Sep 17 00:00:00 2001
+From: Ferruh Yigit <ferruh.yigit@intel.com>
+Date: Mon, 17 May 2021 16:57:39 +0100
+Subject: [PATCH] test/table: fix build with GCC 11
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Build error:
+../app/test/test_table_tables.c: In function ‘test_table_stub’:
+../app/test/test_table_tables.c:31:9:
+ warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0]
+ [-Warray-bounds]
+ memset((uint8_t *)mbuf + sizeof(struct rte_mbuf) + 32, 0, 32); \
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../app/test/test_table_tables.c:151:25:
+ note: in expansion of macro ‘PREPARE_PACKET’
+ 151 | PREPARE_PACKET(mbufs[i], 0xadadadad);
+ | ^~~~~~~~~~~~~~
+
+'key' points to mbuf header + 32 bytes, and memset clears next 32 bytes
+of 'key', so overall there needs to be 64 bytes after mbuf header.
+Adding a mbuf size check before memset.
+
+The original code has an assumption that mbuf data buffer follows mbuf
+header, this patch accepts same assumption.
+
+Bugzilla ID: 677
+Fixes: 5205954791cb ("app/test: packet framework unit tests")
+Cc: stable@dpdk.org
+
+Upstream-Status: Backport [https://github.com/DPDK/dpdk/commit/33c12ac5ba5f09727c6de807e71403dd260a7bbc]
+
+Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
+Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
+---
+ app/test/test_table_tables.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/app/test/test_table_tables.c b/app/test/test_table_tables.c
+index 1aa269f95..4ff6ab16a 100644
+--- a/app/test/test_table_tables.c
++++ b/app/test/test_table_tables.c
+@@ -28,7 +28,8 @@ table_test table_tests[] = {
+ APP_METADATA_OFFSET(0)); \
+ key = RTE_MBUF_METADATA_UINT8_PTR(mbuf, \
+ APP_METADATA_OFFSET(32)); \
+- memset(key, 0, 32); \
++ if (mbuf->priv_size + mbuf->buf_len >= 64) \
++ memset(key, 0, 32); \
+ k32 = (uint32_t *) key; \
+ k32[0] = (value); \
+ *signature = pipeline_test_hash(key, NULL, 0, 0); \
+--
+2.17.1
+
diff --git a/recipes-extended/dpdk/dpdk_19.11.5.bb b/recipes-extended/dpdk/dpdk_19.11.5.bb
index 8410c8a..2ae9b43 100644
--- a/recipes-extended/dpdk/dpdk_19.11.5.bb
+++ b/recipes-extended/dpdk/dpdk_19.11.5.bb
@@ -4,7 +4,8 @@ SRC_URI += " \
file://dpdk-16.04-add-RTE_KERNELDIR_OUT-to-split-kernel-bu.patch \
file://dpdk-16.07-add-sysroot-option-within-app-makefile.patch \
file://0001-Starting-from-Linux-5.9-get_user_pages_remote-API-do.patch \
- file://usertools-devbind-fix-binding-for-built-in-kernel-dr.patch"
+ file://usertools-devbind-fix-binding-for-built-in-kernel-dr.patch \
+ file://0001-test-table-fix-build-with-GCC-11.patch"


STABLE = "-stable"
--
2.29.2


Re: [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1

Andrei Gherzan
 

Hi,

On Wed, 19 May 2021, at 07:08, Naveen Saini wrote:


> -----Original Message-----
> From: yocto@... <yocto@...> On
> Behalf Of Jon Mason
> Sent: Wednesday, May 19, 2021 12:00 AM
> To: Zbigniew Bodek <zbigniew.bodek@...>
> Cc: Wojciech Zmuda <zmuda.w@...>; yocto@...
> Subject: Re: [yocto] [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set
> default preferred version to 2.6.0-rc1

> On Tue, May 18, 2021 at 11:24 AM Zbigniew Bodek
> >
> > Hello Jon,
> >
> > Thanks for your comment. I will try to answer.
> > This change is to include following bug fix:
> > I can also see we've had multiple RC versions in the past but in principle, I'm
> not against your suggestion to have master-next, etc. So where should we go
> from here?

> My recommendation would be to pull that patch out and apply it directly on
> top of v2.5.0 (assuming that is feasible).  Maybe even asking the upstream
> zephyr project to port this to v2.5.0 and make it
> v2.5.1 would be the optimal solution.

[Naveen]  We can wait for stable release. If it is urgent, we can carry patches for bug fixes,  in case upstream does not give dot release !

Even if we don't have the 2.6.0-rc1 release default (to which I agree), I still think having support for it (as a non default) is beneficial. Especially given that 2.6.0 will be an LTS so people might want early (opt-in) support for the time being.

-- 
Andrei Gherzan 
gpg: rsa4096/D4D94F67AD0E9640



Re: hostile freenode takeover

Khem Raj
 

On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:



On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

Thanks for your email. We are aware, and have started to look into that.

It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free!
perhaps good time to consider matrix




- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/



-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmClQWsACgkQYgqew07V
MNUqVgf/awf7Sy5zSw1m5hZJTk7qQHQD3mMhLCH6UWnJoi3RtcF+Le8ZGTquEOGs
fQREEASj2ydMn7PI5RdLzVZRW9AoOShJ7SbscsD2FsjAVn1AI77KC8XHed8kp1Bx
6QNsxiOaLGVdGRRteArSmj2CH8An0X/36Aj5eGRcoiWRTES6xuBcttfeQfahvNld
HJWoT5FjDF7pYdsLBxIHrw/rCAZnScyE6+BiRok0tv6dI5FGqoL4vo0PsT/3hX+C
AI/P5ORyl96XDnxFkc/8J08tIJaOuMYjMVc7XosQ3BAVcg2I9bdEIj/ZSideZaGe
DkW7vIolZaxaj5cO6/koVH9V1gVMnA==
=HI7v
-----END PGP SIGNATURE-----




Re: hostile freenode takeover

Joe MacDonald
 

OFTC is very good, IMO. It's been reliable, well managed, provides a good selection of services, provides a web client for anyone not particularly familiar with IRC clients,  and supports SSL + CertFP in addition to standard auth mechanisms.

-J.

On Wed, May 19, 2021 at 12:56 PM Nicolas Dechesne <nicolas.dechesne@...> wrote:


On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@...> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

Thanks for your email. We are aware, and have started to look into that. 

It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free! 
 

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@...

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/



-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmClQWsACgkQYgqew07V
MNUqVgf/awf7Sy5zSw1m5hZJTk7qQHQD3mMhLCH6UWnJoi3RtcF+Le8ZGTquEOGs
fQREEASj2ydMn7PI5RdLzVZRW9AoOShJ7SbscsD2FsjAVn1AI77KC8XHed8kp1Bx
6QNsxiOaLGVdGRRteArSmj2CH8An0X/36Aj5eGRcoiWRTES6xuBcttfeQfahvNld
HJWoT5FjDF7pYdsLBxIHrw/rCAZnScyE6+BiRok0tv6dI5FGqoL4vo0PsT/3hX+C
AI/P5ORyl96XDnxFkc/8J08tIJaOuMYjMVc7XosQ3BAVcg2I9bdEIj/ZSideZaGe
DkW7vIolZaxaj5cO6/koVH9V1gVMnA==
=HI7v
-----END PGP SIGNATURE-----








--
Joe MacDonald
:wq


Re: hostile freenode takeover

Nicolas Dechesne
 



On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@...> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

Thanks for your email. We are aware, and have started to look into that. 

It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free! 
 

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@...

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/



-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmClQWsACgkQYgqew07V
MNUqVgf/awf7Sy5zSw1m5hZJTk7qQHQD3mMhLCH6UWnJoi3RtcF+Le8ZGTquEOGs
fQREEASj2ydMn7PI5RdLzVZRW9AoOShJ7SbscsD2FsjAVn1AI77KC8XHed8kp1Bx
6QNsxiOaLGVdGRRteArSmj2CH8An0X/36Aj5eGRcoiWRTES6xuBcttfeQfahvNld
HJWoT5FjDF7pYdsLBxIHrw/rCAZnScyE6+BiRok0tv6dI5FGqoL4vo0PsT/3hX+C
AI/P5ORyl96XDnxFkc/8J08tIJaOuMYjMVc7XosQ3BAVcg2I9bdEIj/ZSideZaGe
DkW7vIolZaxaj5cO6/koVH9V1gVMnA==
=HI7v
-----END PGP SIGNATURE-----




hostile freenode takeover

Jasper Orschulko
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/



-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmClQWsACgkQYgqew07V
MNUqVgf/awf7Sy5zSw1m5hZJTk7qQHQD3mMhLCH6UWnJoi3RtcF+Le8ZGTquEOGs
fQREEASj2ydMn7PI5RdLzVZRW9AoOShJ7SbscsD2FsjAVn1AI77KC8XHed8kp1Bx
6QNsxiOaLGVdGRRteArSmj2CH8An0X/36Aj5eGRcoiWRTES6xuBcttfeQfahvNld
HJWoT5FjDF7pYdsLBxIHrw/rCAZnScyE6+BiRok0tv6dI5FGqoL4vo0PsT/3hX+C
AI/P5ORyl96XDnxFkc/8J08tIJaOuMYjMVc7XosQ3BAVcg2I9bdEIj/ZSideZaGe
DkW7vIolZaxaj5cO6/koVH9V1gVMnA==
=HI7v
-----END PGP SIGNATURE-----


[meta-security][PATCH 3/3] sssd: update to 2.5.0

Armin Kuster
 

Add new depends
Drop obsolete patches

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
...AC_CHECK_FILE-when-building-manpages.patch | 34 --------
...s-Collision-with-external-nss-symbol.patch | 78 -------------------
...defines-which-otherwise-are-availabl.patch | 32 --------
.../sssd/files/fix-ldblibdir.patch | 25 ------
recipes-security/sssd/files/fix_gid.patch | 27 +++++++
recipes-security/sssd/files/no_gen.patch | 19 +++++
.../sssd/{sssd_1.16.5.bb => sssd_2.5.0.bb} | 23 +++---
7 files changed, 56 insertions(+), 182 deletions(-)
delete mode 100644 recipes-security/sssd/files/0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch
delete mode 100644 recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch
delete mode 100644 recipes-security/sssd/files/0002-Provide-missing-defines-which-otherwise-are-availabl.patch
delete mode 100644 recipes-security/sssd/files/fix-ldblibdir.patch
create mode 100644 recipes-security/sssd/files/fix_gid.patch
create mode 100644 recipes-security/sssd/files/no_gen.patch
rename recipes-security/sssd/{sssd_1.16.5.bb => sssd_2.5.0.bb} (86%)

diff --git a/recipes-security/sssd/files/0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch b/recipes-security/sssd/files/0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch
deleted file mode 100644
index b64670c..0000000
--- a/recipes-security/sssd/files/0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From d54aa109600bcd02bf72cfe64c01935890a102a1 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= <jonatan.p@gmail.com>
-Date: Fri, 21 Aug 2020 14:45:10 +0200
-Subject: [PATCH] build: Don't use AC_CHECK_FILE when building manpages
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-AC_CHECK_FILE does not support cross-compilation, and will only check
-the host rootfs. Replace AC_CHECK_FILE with a 'test -f <FILE>' instead,
-to allow building manpages when cross-compiling.
-
-Upstream-status: Submitted [https://github.com/SSSD/sssd/pull/5289]
-Signed-off-by: Jonatan Pålsson <jonatan.p@gmail.com>
----
- src/external/docbook.m4 | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/external/docbook.m4 b/src/external/docbook.m4
-index deb8632fa..acdc89a68 100644
---- a/src/external/docbook.m4
-+++ b/src/external/docbook.m4
-@@ -18,7 +18,7 @@ dnl Checks if the XML catalog given by FILE exists and
- dnl if a particular URI appears in the XML catalog
- AC_DEFUN([CHECK_STYLESHEET],
- [
-- AC_CHECK_FILE($1, [], [AC_MSG_ERROR([could not find XML catalog])])
-+ AS_IF([test -f "$1"], [], [AC_MSG_ERROR([could not find XML catalog])])
-
- AC_MSG_CHECKING([for ifelse([$3],,[$2],[$3]) in XML catalog])
- if AC_RUN_LOG([$XSLTPROC --catalogs --nonet --noout "$2" >&2]); then
---
-2.26.1
-
diff --git a/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch b/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch
deleted file mode 100644
index c319269..0000000
--- a/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch
+++ /dev/null
@@ -1,78 +0,0 @@
-From 05c315100a70d3372e891e9a0ea981a875b2ec90 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Michal=20=C5=BDidek?= <mzidek@redhat.com>
-Date: Thu, 27 Feb 2020 06:50:40 +0100
-Subject: [PATCH] nss: Collision with external nss symbol
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-One of our internal static function names started
-to collide with external nss symbol. Additional
-sss_ suffix was added to avoid the collision.
-
-This is needed to unblock Fedora Rawhide's
-SSSD build.
-
-Reviewed-by: Pavel Březina <pbrezina@redhat.com>
-
-Upstream-Status: Backport [https://github.com/SSSD/sssd.git]
-Signed-off-by: Hongxu.jia@windriver.com
-Signed-off-by: Qi.Chen@windriver.com
----
- src/responder/nss/nss_cmd.c | 18 ++++++++++--------
- 1 file changed, 10 insertions(+), 8 deletions(-)
-
-diff --git a/src/responder/nss/nss_cmd.c b/src/responder/nss/nss_cmd.c
-index 25e663ed5..a4d4cfc0b 100644
---- a/src/responder/nss/nss_cmd.c
-+++ b/src/responder/nss/nss_cmd.c
-@@ -728,11 +728,13 @@ done:
- talloc_free(cmd_ctx);
- }
-
--static void nss_setnetgrent_done(struct tevent_req *subreq);
-+static void sss_nss_setnetgrent_done(struct tevent_req *subreq);
-
--static errno_t nss_setnetgrent(struct cli_ctx *cli_ctx,
-- enum cache_req_type type,
-- nss_protocol_fill_packet_fn fill_fn)
-+/* This function's name started to collide with external nss symbol,
-+ * so it has additional sss_* prefix unlike other functions here. */
-+static errno_t sss_nss_setnetgrent(struct cli_ctx *cli_ctx,
-+ enum cache_req_type type,
-+ nss_protocol_fill_packet_fn fill_fn)
- {
- struct nss_ctx *nss_ctx;
- struct nss_state_ctx *state_ctx;
-@@ -774,7 +776,7 @@ static errno_t nss_setnetgrent(struct cli_ctx *cli_ctx,
- goto done;
- }
-
-- tevent_req_set_callback(subreq, nss_setnetgrent_done, cmd_ctx);
-+ tevent_req_set_callback(subreq, sss_nss_setnetgrent_done, cmd_ctx);
-
- ret = EOK;
-
-@@ -787,7 +789,7 @@ done:
- return EOK;
- }
-
--static void nss_setnetgrent_done(struct tevent_req *subreq)
-+static void sss_nss_setnetgrent_done(struct tevent_req *subreq)
- {
- struct nss_cmd_ctx *cmd_ctx;
- errno_t ret;
-@@ -1037,8 +1039,8 @@ static errno_t nss_cmd_initgroups_ex(struct cli_ctx *cli_ctx)
-
- static errno_t nss_cmd_setnetgrent(struct cli_ctx *cli_ctx)
- {
-- return nss_setnetgrent(cli_ctx, CACHE_REQ_NETGROUP_BY_NAME,
-- nss_protocol_fill_setnetgrent);
-+ return sss_nss_setnetgrent(cli_ctx, CACHE_REQ_NETGROUP_BY_NAME,
-+ nss_protocol_fill_setnetgrent);
- }
-
- static errno_t nss_cmd_getnetgrent(struct cli_ctx *cli_ctx)
---
-2.21.0
-
diff --git a/recipes-security/sssd/files/0002-Provide-missing-defines-which-otherwise-are-availabl.patch b/recipes-security/sssd/files/0002-Provide-missing-defines-which-otherwise-are-availabl.patch
deleted file mode 100644
index 1a22332..0000000
--- a/recipes-security/sssd/files/0002-Provide-missing-defines-which-otherwise-are-availabl.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-From 37a0999e5a9f54e1c61a02a7fbab6fcd04738b3c Mon Sep 17 00:00:00 2001
-From: Armin Kuster <akuster808@gmail.com>
-Date: Thu, 8 Oct 2020 05:54:13 -0700
-Subject: [PATCH] Provide missing defines which otherwise are available on
- glibc system headers
-
-Signed-off-by: Armin Kuster <akuster808@gmail.com>
-
-Upsteam-Status: Pending
-
----
- src/util/util.h | 4 ++++
- 1 file changed, 4 insertions(+)
-
-diff --git a/src/util/util.h b/src/util/util.h
-index 8a754dbfd..6e55b4bdc 100644
---- a/src/util/util.h
-+++ b/src/util/util.h
-@@ -76,6 +76,10 @@
- #define MAX(a, b) (((a) > (b)) ? (a) : (b))
- #endif
-
-+#ifndef ALLPERMS
-+# define ALLPERMS (S_ISUID|S_ISGID|S_ISVTX|S_IRWXU|S_IRWXG|S_IRWXO)/* 07777 */
-+#endif
-+
- #define SSSD_MAIN_OPTS SSSD_DEBUG_OPTS
-
- #define SSSD_SERVER_OPTS(uid, gid) \
---
-2.17.1
-
diff --git a/recipes-security/sssd/files/fix-ldblibdir.patch b/recipes-security/sssd/files/fix-ldblibdir.patch
deleted file mode 100644
index e350baf..0000000
--- a/recipes-security/sssd/files/fix-ldblibdir.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-When calculate value of ldblibdir, it checks whether the directory of
-$ldblibdir exists. If not, it assigns ldblibdir with ${libdir}/ldb. It is not
-suitable for cross compile. Fix it that only re-assign ldblibdir when its value
-is empty.
-
-Upstream-Status: Inappropriate [cross compile specific]
-
-Signed-off-by: Kai Kang <kai.kang@windriver.com>
----
- src/external/libldb.m4 | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/external/libldb.m4 b/src/external/libldb.m4
-index c400add..5e5f06d 100644
---- a/src/external/libldb.m4
-+++ b/src/external/libldb.m4
-@@ -19,7 +19,7 @@ if test x"$with_ldb_lib_dir" != x; then
- ldblibdir=$with_ldb_lib_dir
- else
- ldblibdir="`$PKG_CONFIG --variable=modulesdir ldb`"
-- if ! test -d $ldblibdir; then
-+ if test -z $ldblibdir; then
- ldblibdir="${libdir}/ldb"
- fi
- fi
diff --git a/recipes-security/sssd/files/fix_gid.patch b/recipes-security/sssd/files/fix_gid.patch
new file mode 100644
index 0000000..9b481cc
--- /dev/null
+++ b/recipes-security/sssd/files/fix_gid.patch
@@ -0,0 +1,27 @@
+from ../sssd-2.5.0/src/util/sss_pam_data.c:27:
+| ../sssd-2.5.0/src/util/debug.h:88:44: error: unknown type name 'uid_t'; did you mean 'uint_t'?
+| 88 | int chown_debug_file(const char *filename, uid_t uid, gid_t gid);
+| | ^~~~~
+| | uint_t
+| ../sssd-2.5.0/src/util/debug.h:88:55: error: unknown type name 'gid_t'
+| 88 | int chown_debug_file(const char *filename, uid_t uid, gid_t gid);
+| | ^~~~~
+| make[2]: *** [Makefile:22529: src/util/libsss_iface_la-sss_pam_data.lo] Error 1
+| make[2]: *** Waiting for unfinished jobs....
+
+Upstream-Status: Pending
+Signed-off-by: Armin Kuster <akuster808@gmail.com>
+
+Index: sssd-2.5.0/src/util/debug.h
+===================================================================
+--- sssd-2.5.0.orig/src/util/debug.h
++++ sssd-2.5.0/src/util/debug.h
+@@ -24,6 +24,8 @@
+ #include "config.h"
+
+ #include <stdio.h>
++#include <unistd.h>
++#include <sys/types.h>
+ #include <stdbool.h>
+
+ #include "util/util_errors.h"
diff --git a/recipes-security/sssd/files/no_gen.patch b/recipes-security/sssd/files/no_gen.patch
new file mode 100644
index 0000000..5c83777
--- /dev/null
+++ b/recipes-security/sssd/files/no_gen.patch
@@ -0,0 +1,19 @@
+don't run generate-sbus-code
+
+Upstream-Status: Inappropriate [OE Specific]
+
+Signed-off-by: Armin Kuster <akuster808@gmail.com>
+
+Index: sssd-2.5.0/Makefile.am
+===================================================================
+--- sssd-2.5.0.orig/Makefile.am
++++ sssd-2.5.0/Makefile.am
+@@ -1033,8 +1033,6 @@ generate-sbus-code:
+
+ .PHONY: generate-sbus-code
+
+-BUILT_SOURCES += generate-sbus-code
+-
+ EXTRA_DIST += \
+ sbus_generate.sh.in \
+ src/sbus/codegen/dbus.xml \
diff --git a/recipes-security/sssd/sssd_1.16.5.bb b/recipes-security/sssd/sssd_2.5.0.bb
similarity index 86%
rename from recipes-security/sssd/sssd_1.16.5.bb
rename to recipes-security/sssd/sssd_2.5.0.bb
index 9784ec7..a49f7c7 100644
--- a/recipes-security/sssd/sssd_1.16.5.bb
+++ b/recipes-security/sssd/sssd_2.5.0.bb
@@ -5,8 +5,8 @@ SECTION = "base"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"

-DEPENDS = "openldap cyrus-sasl libtdb ding-libs libpam c-ares krb5 autoconf-archive"
-DEPENDS_append = " libldb dbus libtalloc libpcre glib-2.0 popt e2fsprogs libtevent"
+DEPENDS = "acl attr openldap cyrus-sasl libtdb ding-libs libpam c-ares krb5 autoconf-archive"
+DEPENDS_append = " libldb dbus libtalloc libpcre glib-2.0 popt e2fsprogs libtevent bind p11-kit"

DEPENDS_append_libc-musl = " musl-nscd"

@@ -15,16 +15,13 @@ DEPENDS_append_libc-musl = " musl-nscd"
DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'nss', '', \
bb.utils.contains('PACKAGECONFIG', 'crypto', '', 'nss', d), d)}"

-SRC_URI = "https://releases.pagure.org/SSSD/${BPN}/${BP}.tar.gz \
+SRC_URI = "https://github.com/SSSD/sssd/releases/download/2.5.0/sssd-2.5.0.tar.gz \
file://sssd.conf \
file://volatiles.99_sssd \
- file://fix-ldblibdir.patch \
- file://0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch \
- file://0001-nss-Collision-with-external-nss-symbol.patch \
- file://0002-Provide-missing-defines-which-otherwise-are-availabl.patch \
+ file://no_gen.patch \
+ file://fix_gid.patch \
"
-
-SRC_URI[sha256sum] = "2e1a7bf036b583f686d35164f2d79bdf4857b98f51fe8b0d17aa0fa756e4d0c0"
+SRC_URI[sha256sum] = "afa62d7d8d23fca3aba093abe4ec0d14e7d9346c5b28ceb7c2c624bed98caa06"

inherit autotools pkgconfig gettext python3-dir features_check systemd

@@ -34,7 +31,7 @@ SSSD_UID ?= "root"
SSSD_GID ?= "root"

CACHED_CONFIGUREVARS = "ac_cv_member_struct_ldap_conncb_lc_arg=no \
- ac_cv_path_NSUPDATE=${bindir} ac_cv_prog_HAVE_PYTHON3=${PYTHON_DIR} \
+ ac_cv_path_NSUPDATE=${bindir}/nsupdate ac_cv_prog_HAVE_PYTHON3=${PYTHON_DIR} \
"

PACKAGECONFIG ?="nss nscd autofs sudo infopipe"
@@ -42,13 +39,13 @@ PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux',
PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)}"

PACKAGECONFIG[autofs] = "--with-autofs, --with-autofs=no"
-PACKAGECONFIG[crypto] = "--with-crypto=libcrypto, , libcrypto"
+PACKAGECONFIG[crypto] = ", , libcrypto"
PACKAGECONFIG[curl] = "--with-kcm, --without-kcm, curl jansson"
PACKAGECONFIG[infopipe] = "--with-infopipe, --with-infopipe=no, "
PACKAGECONFIG[manpages] = "--with-manpages, --with-manpages=no, libxslt-native docbook-xml-dtd4-native docbook-xsl-stylesheets-native"
PACKAGECONFIG[nl] = "--with-libnl, --with-libnl=no, libnl"
PACKAGECONFIG[nscd] = "--with-nscd=${sbindir}, --with-nscd=no "
-PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss,"
+PACKAGECONFIG[nss] = ", ,nss,"
PACKAGECONFIG[python3] = "--with-python3-bindings, --without-python3-bindings"
PACKAGECONFIG[samba] = "--with-samba, --with-samba=no, samba"
PACKAGECONFIG[selinux] = "--with-selinux, --with-selinux=no --with-semanage=no, libselinux"
@@ -119,7 +116,7 @@ SYSTEMD_SERVICE_${PN} = " \
"
SYSTEMD_AUTO_ENABLE = "disable"

-FILES_${PN} += "${libdir} ${datadir} ${base_libdir}/security/pam_sss.so"
+FILES_${PN} += "${libdir} ${datadir} ${base_libdir}/security/pam_sss*.so"
FILES_${PN}-dev = " ${includedir}/* ${libdir}/*la ${libdir}/*/*la"

# The package contains symlinks that trip up insane
--
2.24.3


[meta-security][PATCH 2/3] ossec-hids: musl not compatable

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-ids/ossec/ossec-hids_3.6.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-ids/ossec/ossec-hids_3.6.0.bb b/recipes-ids/ossec/ossec-hids_3.6.0.bb
index 242bbdb..778278b 100644
--- a/recipes-ids/ossec/ossec-hids_3.6.0.bb
+++ b/recipes-ids/ossec/ossec-hids_3.6.0.bb
@@ -161,3 +161,5 @@ USERADD_PARAM_${PN} = "--system --home-dir /var/ossec -g ossec --shell /bin/fals
GROUPADD_PARAM_${PN} = "--system ossec"

RDEPENDS_${PN} = "openssl bash"
+
+COMPATIBLE_HOST_libc-musl = "null"
--
2.24.3


[meta-security][PATCH 1/3] packagegroup-core-security: exclude ossec-hids from musl

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index d7349b0..cf9620f 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -74,6 +74,8 @@ RDEPENDS_packagegroup-security-ids = " \
aide \
"

+RDEPENDS_packagegroup-security-ids_remove_libc-musl = "ossec-hids"
+
SUMMARY_packagegroup-security-mac = "Security Mandatory Access Control systems"
RDEPENDS_packagegroup-security-mac = " \
${@bb.utils.contains("DISTRO_FEATURES", "tomoyo", "ccs-tools", "",d)} \
--
2.24.3


[yocto-autobuilder2][dunfell] config.py: enable fedora33 workers for dunfell

Steve Sakoman
 

Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.py b/config.py
index 520de47..2565bd7 100644
--- a/config.py
+++ b/config.py
@@ -150,7 +150,7 @@ all_workers = workers + workers_bringup + workers_buildperf + workers_arm
workers_prev_releases = {
"hardknott" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora31", "fedora32", "fedora33", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu2004", "perf-"),
"gatesgarth" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora30", "fedora31", "fedora32", "opensuse150", "opensuse151", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
- "dunfell" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora29", "fedora30", "fedora31", "fedora32", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
+ "dunfell" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora29", "fedora30", "fedora31", "fedora32", "fedora33", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
"zeus" : ("centos7", "debian8", "debian9", "debian10", "fedora28", "fedora29", "fedora30", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "perf-"),
"warrior" : ("centos7", "debian8", "debian9", "debian10", "fedora28", "fedora29", "fedora30", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "perf-"),
"thud" : ("centos7", "debian8", "debian9", "debian10", "fedora28", "fedora29", "fedora30", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "perf-"),
--
2.25.1


Re: PREEMPT_RT patches

codusnocturnus
 

Yocto has supported a PREEMPT_RT kernel as long as I can remember.

There are recipes for linux-yocto-rt for the kernel itself, and a core-image-rt image recipe right in poky.

It's also pretty straightforward to use a different kernel recipe, such as one from a vendor, and apply the PREEMPT_RT patches in a .bbappend, provided the recipe version lines up with the patches.

Thanks,


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Wednesday, May 19, 2021 3:51 AM, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

Recently I heard somewhere that newer versions of the Linux Kernel will include the PREEMPT_RT patches, and configuration settings would be used to set how the Linux would operate in a specific system.

 

Does Yocto support “PREEMPT_RT”, and what versions of Yocto have this option ?

 

Is there documentation on this feature/option ?

 

Thanks,

Steve

 



Re: PREEMPT_RT patches

Leon Woestenberg
 

Hello Steven,

Yocto does support switching kernels and configurations, so yes Yocto does "support" it.

However, providing a well-tested PREEMPT_RT kernel might be more an architectural meta layer topic.

We have been using the Intel provided PREEMPT_RT kernel for x86 with good success in a system with hard real-time requirements.
In the end we chose full task isolation approach, where one task runs in user-space task isolation, reducing latencies even further than what PREEMPT_RT can provide, as we did not need kernel services in our main processing loop (after setup).

Regards,

Leon.


On Wed, May 19, 2021 at 12:53 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

Recently I heard somewhere that newer versions of the Linux Kernel will include the PREEMPT_RT patches, and configuration settings would be used to set how the Linux would operate in a specific system.

 

Does Yocto support “PREEMPT_RT”, and what versions of Yocto have this option ?

 

Is there documentation on this feature/option ?

 

Thanks,

Steve

 





[meta-zephyr][PATCH v2 2/2] nrf52840dk-nrf52840.conf: Add nRF52840 DK support

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@huawei.com>

Add support for Nordic Semiconductor nRF52840 Development
Kit board.

This is a generic MACHINE over nRF52 SoC family config
plus PyOCD flashing ability.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
---
conf/machine/nrf52840dk-nrf52840.conf | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 conf/machine/nrf52840dk-nrf52840.conf

diff --git a/conf/machine/nrf52840dk-nrf52840.conf b/conf/machine/nrf52840dk-nrf52840.conf
new file mode 100644
index 0000000..c5be5db
--- /dev/null
+++ b/conf/machine/nrf52840dk-nrf52840.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: nrf52840dk-nrf52840
+
+#@DESCRIPTION: Machine configuration for Nordic Semiconductor nRF52840 Development Kit.
+
+require conf/machine/include/nrf52.inc
+ZEPHYR_INHERIT_CLASSES += "zephyr-flash-pyocd"
+ARCH_nrf52840dk-nrf52840 = "arm"
--
2.25.1

1901 - 1920 of 55465