yocto@lists.yoctoproject.org

Home Messages Hashtags Subgroups

Expanded

Between

and

Re: hostile freenode takeover Nicolas Dechesne <nicolas.dechesne@...> #53596 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
More All Messages By This Member
Re: hostile freenode takeover Quentin Schulz #53595 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¢. Cheers, Quentin
More All Messages By This Member
Re: [meta-zephyr][PATCH] qemuzephyrrunner.py: use existing qemu conf file Naveen Saini #53594 Hi Jon, toggle quoted message Show quoted text -----Original Message----- From: yocto@... <yocto@...> On Behalf Of Jon Mason Sent: Tuesday, May 18, 2021 11:10 PM To: yocto@... 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@...> --- 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() + 605 + 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
More All Messages By This Member
[meta-dpdk][PATCH] dpdk: fix build with GCC 11 Yu, Mingli #53593 From: Mingli Yu <mingli.yu@...> 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@...> --- ...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@...> +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@... + +Upstream-Status: Backport [https://github.com/DPDK/dpdk/commit/33c12ac5ba5f09727c6de807e71403dd260a7bbc] + +Signed-off-by: Ferruh Yigit <ferruh.yigit@...> +Signed-off-by: Mingli Yu <mingli.yu@...> +--- + 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
More All Messages By This Member
Re: [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1 Andrei Gherzan #53592 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 > <zbigniew.bodek@...> wrote: > > > > Hello Jon, > > > > Thanks for your comment. I will try to answer. > > This change is to include following bug fix: > > https://github.com/zephyrproject-rtos/zephyr/pull/33251 > > 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
More All Messages By This Member
Re: hostile freenode takeover Khem Raj #53591 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 - -- 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-----
More All Messages By This Member
Re: hostile freenode takeover Joe MacDonald #53590 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. toggle quoted message Show quoted text 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
More All Messages By This Member
Re: hostile freenode takeover Nicolas Dechesne <nicolas.dechesne@...> #53589 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-----
More All Messages By This Member
hostile freenode takeover Jasper Orschulko #53588 -----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-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-----
More All Messages By This Member
[meta-security][PATCH 3/3] sssd: update to 2.5.0 Armin Kuster #53587 Add new depends Drop obsolete patches Signed-off-by: Armin Kuster <akuster808@...> --- ...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@...> -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@...> ---- - 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@...> -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@...> - -Upstream-Status: Backport [https://github.com/SSSD/sssd.git] -Signed-off-by: Hongxu.jia@... -Signed-off-by: Qi.Chen@... ---- - 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@...> -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@...> - -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@...> ---- - 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@...> + +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@...> + +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
More All Messages By This Member
[meta-security][PATCH 2/3] ossec-hids: musl not compatable Armin Kuster #53586 Signed-off-by: Armin Kuster <akuster808@...> --- 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
More All Messages By This Member
[meta-security][PATCH 1/3] packagegroup-core-security: exclude ossec-hids from musl Armin Kuster #53585 Signed-off-by: Armin Kuster <akuster808@...> --- 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
More All Messages By This Member
[yocto-autobuilder2][dunfell] config.py: enable fedora33 workers for dunfell Steve Sakoman #53584 Signed-off-by: Steve Sakoman <steve@...> --- 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
More All Messages By This Member
Re: PREEMPT_RT patches codusnocturnus #53583 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: toggle quoted message Show quoted text 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
More All Messages By This Member
Re: PREEMPT_RT patches Leon Woestenberg #53582 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: toggle quoted message Show quoted text 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
More All Messages By This Member
[meta-zephyr][PATCH v2 2/2] nrf52840dk-nrf52840.conf: Add nRF52840 DK support Wojciech Zmuda #53581 From: Wojciech Zmuda <wojciech.zmuda@...> 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@...> --- 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
More All Messages By This Member
[meta-zephyr][PATCH v2 1/2] nrf52832.inc: Rename to nrf52.inc Wojciech Zmuda #53580 From: Wojciech Zmuda <wojciech.zmuda@...> The file is so generic anyway it can be targeted for the nRF52 family without any harm. Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...> --- conf/machine/96b-nitrogen.conf \| 2 +- conf/machine/include/{nrf52832.inc => nrf52.inc} \| 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) rename conf/machine/include/{nrf52832.inc => nrf52.inc} (86%) diff --git a/conf/machine/96b-nitrogen.conf b/conf/machine/96b-nitrogen.conf index 998db4c..48f2041 100644 --- a/conf/machine/96b-nitrogen.conf +++ b/conf/machine/96b-nitrogen.conf @@ -3,6 +3,6 @@ #@DESCRIPTION: Machine configuration for 96Boards Nitrogen Board. -require conf/machine/include/nrf52832.inc +require conf/machine/include/nrf52.inc ZEPHYR_INHERIT_CLASSES += "zephyr-flash-pyocd" ARCH_96b-nitrogen = "arm" diff --git a/conf/machine/include/nrf52832.inc b/conf/machine/include/nrf52.inc similarity index 86% rename from conf/machine/include/nrf52832.inc rename to conf/machine/include/nrf52.inc index e938aa6..d22f8bc 100644 --- a/conf/machine/include/nrf52832.inc +++ b/conf/machine/include/nrf52.inc @@ -1,7 +1,7 @@ #@TYPE: Machine -#@NAME: nrf52832 +#@NAME: nrf52xxx -#@DESCRIPTION: Machine configuration for Nordic Semiconductor nRF52832 (Cortex-M4) SoC. +#@DESCRIPTION: Machine configuration for Nordic Semiconductor nRF52xxx (Cortex-M4) SoC. require conf/machine/include/tune-cortexm4.inc -- 2.25.1
More All Messages By This Member
[meta-zephyr][PATCH v2 0/2] Add nRF52840 DK support Wojciech Zmuda #53579 From: Wojciech Zmuda <wojciech.zmuda@...> v1 -> v2: - MACHINE configurations are named using '-' instead of '_'. Reame the new configuration accordingly. This patch set adds support for Nordic Semiconductor nRF5284 Development Kit board. Since there already is nRF52xx family chip support added (specifically nRF52832 used in 96Boards Nitrogen), make this support a bit more generic to cover the whole family, then add a platform-specific configs for both nRF-based boards on top of it. The change has been tested with the actual nRF52840 DK board by building and flashing with `-c flash_usb` some sample applications. Wojciech Zmuda (2): nrf52832.inc: Rename to nrf52.inc nrf52840dk-nrf52840.conf: Add nRF52840 DK support conf/machine/96b-nitrogen.conf \| 2 +- conf/machine/include/{nrf52832.inc => nrf52.inc} \| 4 ++-- conf/machine/nrf52840dk-nrf52840.conf \| 8 ++++++++ 3 files changed, 11 insertions(+), 3 deletions(-) rename conf/machine/include/{nrf52832.inc => nrf52.inc} (86%) create mode 100644 conf/machine/nrf52840dk-nrf52840.conf -- 2.25.1
More All Messages By This Member
Re: [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1 Wojciech Zmuda #53578 Hello everybody, thanks for your comments. Let's abandon this patch then. Judging by meta-zephyr commit history we guessed that bumping up the rev to -rc is compliant with your policy. In that case we, as meta-zephyr users, will just wait for the upstream to reach stable 2.6.0. Regards, Wojciech toggle quoted message Show quoted text On Wed, 19 May 2021 at 08:08, Saini, Naveen Kumar <naveen.kumar.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 > <zbigniew.bodek@...> wrote: > > > > Hello Jon, > > > > Thanks for your comment. I will try to answer. > > This change is to include following bug fix: > > https://github.com/zephyrproject-rtos/zephyr/pull/33251 > > 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 ! > As far as a master-next branch, that would be up to Naveen. > > > > > Kind regards > > Zbigniew > > > > -----Original Message----- > > From: Jon Mason [mailto:jdmason@...] > > Sent: 18 May, 2021 17:17 > > To: Wojciech Zmuda <zmuda.w@...> > > Cc: yocto@...; Zbigniew Bodek > > <zbigniew.bodek@...> > > 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 8:30 AM Wojciech Zmuda <zmuda.w@...> > wrote: > > > > > > From: Zbigniew Bodek <zbigniew.bodek@...> > > > > > > Signed-off-by: Zbigniew Bodek <zbigniew.bodek@...> > > > > Do we really want to have Zephyr on a release candidate? IMHO, we > should never be doing this, as we should want the kernel in meta-zephyr to > be as stable as possible. If this is really desired, perhaps a master-next > branch for things like this. > > > > Thanks, > > Jon > > > > > --- > > > recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc \| 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc > > > b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc > > > index 5ee40d4..9fc08ba 100644 > > > --- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc > > > +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc > > > @@ -2,7 +2,7 @@ LICENSE = "Apache-2.0" > > > LIC_FILES_CHKSUM = > "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc" > > > > > > # Default to a stable version > > > -PREFERRED_VERSION_zephyr-kernel ??= "2.5.0" > > > +PREFERRED_VERSION_zephyr-kernel ??= "2.6.0-rc1" > > > include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc > > > > > > inherit cmake > > > -- > > > 2.25.1 > > > > > > > > > > > >
More All Messages By This Member
PREEMPT_RT patches Monsees, Steven C (US) #53577 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
More All Messages By This Member

6561 - 6580 of 60121

Home Hashtags Subgroups Terms