Re: [OE-core] [PATCH 1/2] insane: Add test for native/nativesdk inherit order
After this patch got merged I notice some "noise" in my builds.
For bbappends which inherit unrelated classes I get a lot of warning like
Issue: nativesdk-openssh: native/nativesdk class is not inherited last,
this can result in unexpected behaviour. Classes inherited after
native/nativesdk: my-custom-class.bbclass [native-last]
First it doesn't give any hint that this is caused by the bbappend and
secondly I have no idea how to fix that (if that is even possible).
So I would like to have at least an option to ignore these warnings for
classes I'm sure don't cause any conflict - something more granular then
just to deactivate this pretty useful check.
Thoughts?
On 24.01.21 10:55, Tomasz Dziendzielski wrote:
Classes native/nativesdk should be inherited last to prevent unexpected
behaviour.
[YOCTO #5729]
Signed-off-by: Tomasz Dziendzielski
---
meta/classes/insane.bbclass | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 105d2a5ce8..3597943ddd 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -27,7 +27,7 @@ WARN_QA ?= " libdir xorg-driver-abi \
infodir build-deps src-uri-bad symlink-to-sysroot multilib \
invalid-packageconfig host-user-contaminated uppercase-pn
patch-fuzz \
mime mime-xdg unlisted-pkg-lics unhandled-features-check \
-missing-update-alternatives \
+missing-update-alternatives native-last \
"
ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch pkgconfig la \
perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
@@ -1366,6 +1366,32 @@ python () {
d.setVarFlag('do_package_qa', 'rdeptask', '')
for i in issues:
package_qa_handle_error("pkgvarcheck", "%s: Variable %s is set as not being package
specific, please fix this." % (d.getVar("FILE"), i), d)
+
+for native_class in ['native', 'nativesdk']:
+if bb.data.inherits_class(native_class, d):
+
+inherited_classes = d.getVar('__inherit_cache', False) or []
+needle = os.path.join('classes', native_class)
+
+bbclassextend = (d.getVar('BBCLASSEXTEND') or '').split()
+# BBCLASSEXTEND items are always added in the end
+skip_classes = bbclassextend
+if bb.data.inherits_class('native', d) or 'native' in
bbclassextend:
+# native also inherits nopackages and relocatable bbclasses
+skip_classes.extend(['nopackages', 'relocatable'])
+
+for class_item in reversed(inherited_classes):
+if needle not in class_item:
+for extend_item in skip_classes:
+if os.path.join('classes', '%s.bbclass' % extend_item)
in class_item:
+break
+else:
+pn = d.getVar('PN')
+package_qa_handle_error("native-last", "%s:
native/nativesdk class is not inherited last, this can result in unexpected behaviour. " % pn,
d)
+break
+else:
+break
+
qa_sane = d.getVar("QA_SANE")
if not qa_sane:
bb.fatal("Fatal QA errors found, failing task.")
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147942):
https://lists.openembedded.org/g/openembedded-core/message/147942
Mute This Topic: https://lists.openembedded.org/mt/80075083/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] connman: update to 1.39
On Wed, 2021-02-10 at 04:32 +, akuster wrote: > [Yocto #14231] > > Bug fix only and includes two security fixes: > > CVE-2021-26676 > CVE-2021-26676 Copy and paste error? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147941): https://lists.openembedded.org/g/openembedded-core/message/147941 Mute This Topic: https://lists.openembedded.org/mt/80524901/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 00/26] Pull request (cover letter only)
The following changes since commit e0cd2e1f9ae956d72b8033ce1c4403d8bd99d3d5:
staging: Clean up files installed into the sysroot (2021-01-29 04:48:10 -1000)
are available in the Git repository at:
git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next
Alexander Kanavin (1):
ca-certificates: correct upstream version check
Anatol Belski (1):
glib-2.0: Rename patch file for CVE-2020-35457
Awais Belal (1):
kernel.bbclass: fix deployment for initramfs images
Bruce Ashfield (3):
linux-yocto/5.4: update to v5.4.90
linux-yocto-rt/5.4: fix 5.4-stable caused build breakage
linux-yocto/5.4: update to v5.4.94
Dorinda (1):
sanity.bbclass: Check if PSEUDO_IGNORE_PATHS and paths under pseudo
control overlap
Julien Massot (1):
rng-tools: fix rngd_jitter initialization
Lee Chee Yang (4):
cve-check: replace Looseversion with custom version class
cve_check: add CVE_VERSION_SUFFIX to indicate suffix in versioning
openssl: set CVE_VERSION_SUFFIX
wic/selftest: test_permissions also test bitbake image
Mark Hatle (1):
package.bbclass: hash equivalency and pr service
Peter Bergin (1):
buildhistory.bbclass: avoid exception for empty BUILDHISTORY_FEATURES
variable
Ricardo Ribalda (1):
classes/image_types_wic: Reorder do_flush_pseudodb
Ricardo Ribalda Delgado (1):
oeqa: wic: Add tests for permissions and change-directory
Richard Purdie (3):
pseudo: Update to include passwd and file renaming fixes
package: Ensure do_packagedata is cleaned correctly
qemu.inc: Should depend on qemu-system-native, not qemu-native
Sourabh Banerjee (1):
layer.conf: fix sanity error for PATH variable in extensible SDK
workflow
Tomasz Dziendzielski (3):
python3: Use addtask statement instead of task dependencies
lib/oe/patch.py: Ignore scissors line on applying patch
sstatesig: Add descriptive error message to getpwuid/getgrgid "uid/gid
not found" KeyError
Vyacheslav Yurkov (1):
npm.bbclass: use python3 for npm config
Wang Mingyu (1):
ca-certificates: upgrade 20190110 -> 20200601
zhengruoqin (1):
ca-certificates: upgrade 20200601 -> 20210119
meta/classes/buildhistory.bbclass | 2 +-
meta/classes/cve-check.bbclass| 14 ++-
meta/classes/image_types_wic.bbclass | 2 +-
meta/classes/kernel.bbclass | 2 +-
meta/classes/npm.bbclass | 6 +-
meta/classes/package.bbclass | 59 --
meta/classes/sanity.bbclass | 10 ++
meta/conf/bitbake.conf| 1 +
meta/conf/layer.conf | 4 +-
meta/conf/machine/include/qemu.inc| 2 +-
meta/lib/oe/cve_check.py | 60 ++
meta/lib/oe/patch.py | 2 +-
meta/lib/oe/sstatesig.py | 6 +-
meta/lib/oeqa/selftest/cases/cve_check.py | 36 ++
meta/lib/oeqa/selftest/cases/prservice.py | 8 +-
meta/lib/oeqa/selftest/cases/wic.py | 106 ++
.../openssl/openssl_1.1.1i.bb | 2 +
...onEntry-lis.patch => CVE-2020-35457.patch} | 0
meta/recipes-core/glib-2.0/glib-2.0_2.62.6.bb | 2 +-
meta/recipes-devtools/pseudo/pseudo_git.bb| 2 +-
meta/recipes-devtools/python/python3_3.8.2.bb | 5 +-
.../linux/linux-yocto-rt_5.4.bb | 6 +-
.../linux/linux-yocto-tiny_5.4.bb | 8 +-
meta/recipes-kernel/linux/linux-yocto_5.4.bb | 22 ++--
.../0001-certdata2pem.py-use-python3.patch| 37 --
...0190110.bb => ca-certificates_20210119.bb} | 6 +-
...-O_NONBLOCK-setting-for-entropy-pipe.patch | 26 +
...ialize-AES-key-before-setting-the-en.patch | 38 +++
...ys-read-from-entropy-pipe-before-set.patch | 38 +++
.../rng-tools/rng-tools_6.9.bb| 3 +
30 files changed, 423 insertions(+), 92 deletions(-)
create mode 100644 meta/lib/oe/cve_check.py
create mode 100644 meta/lib/oeqa/selftest/cases/cve_check.py
rename
meta/recipes-core/glib-2.0/glib-2.0/{0001-goption-Add-a-precondition-to-avoid-GOptionEntry-lis.patch
=> CVE-2020-35457.patch} (100%)
delete mode 100644
meta/recipes-support/ca-certificates/ca-certificates/0001-certdata2pem.py-use-python3.patch
rename meta/recipes-support/ca-certificates/{ca-certificates_20190110.bb =>
ca-certificates_20210119.bb} (93%)
create mode 100644
meta/recipes-support/rng-tools/rng-tools/0001-rngd_jitter-fix-O_NONBLOCK-setting-for-entropy-pipe.patch
create mode 100644
meta/recipes-support/rng-tools/rng-tools/0002-rngd_jitter-initialize-AES-key-before-setting-the-en.patch
create mode 100644
meta/recipes-support/rng-tools/rng-tools/0003-rngd_jitter-always-read-from-entropy-pipe-before-set.patch
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147940):
Re: [OE-core] Next steps for extrausers passwd-expire PR 63?
Hello, Em qua., 10 de fev. de 2021 às 14:27, Joseph Reynolds escreveu: > What are the next steps for this? > https://github.com/openembedded/openembedded-core/pull/63 I reviewed it there and mentioned what is missing. Including suggesting it to be send here for review. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147939): https://lists.openembedded.org/g/openembedded-core/message/147939 Mute This Topic: https://lists.openembedded.org/mt/80537493/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
Em qua., 10 de fev. de 2021 às 17:21, Andrey Zhizhikin escreveu: > On Wed, Feb 10, 2021 at 3:41 PM Ray Smith wrote: > > On Wed, Feb 10, 2021 at 1:26 PM Otavio Salvador < > otavio.salva...@ossystems.com.br> wrote: > >> > >> > >> I didn't understand what you mean here. Could you elaborate this? > >> > > > > If you try to build mesa with PACKAGECONFIG "egl gles dri" you get an > error: > > ../mesa-20.3.2/meson.build:144:4: ERROR: Problem encountered: building > OpenGL ES without OpenGL is not supported. > > > > This means that in practice you can't get a GLES-only build of mesa, so > mesa always provides OpenGL (ignoring Vulkan). But for an abstract graphics > driver that's not true - many drivers provide GLES but not OpenGL. I'd > argue that this is an implementation detail (and maybe a minor bug) of > mesa. If mesa internally requires code from its OpenGL support to build > GLES, it should silently include that if it's been configured for GLES-only. > > > > I only mention it to be clear that in general "GLES requires OpenGL" is > not true, even though mesa's build system enforces that. > > Should this be clarified with Mesa folks upfront? If you believe that > this limitation is rather "artificial", then there has to be a proper > explanation from Mesa developers why OGL is provided when OGLES-only > is built. > Agreed ... I'd rather not drop the check until we hear from upstream the reasoning behind it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147938): https://lists.openembedded.org/g/openembedded-core/message/147938 Mute This Topic: https://lists.openembedded.org/mt/80529198/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] connman: update to 1.39
On 2/10/21 7:54 AM, Oleksandr Kravchuk wrote:
> Changelog:
> - Fix issue with scanning state synchronization and iwd.
> - Fix issue with invalid key with 4-way handshake offloading.
> - Fix issue with DNS proxy length checks to prevent buffer overflow.
> - Fix issue with DHCP leaking stack data via uninitialized variable.
this update was sent last night which included CVE #. either patch will
do IMHO
-armin
>
> Signed-off-by: Oleksandr Kravchuk
> ---
> .../connman/{connman_1.38.bb => connman_1.39.bb} | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
> rename meta/recipes-connectivity/connman/{connman_1.38.bb =>
> connman_1.39.bb} (78%)
>
> diff --git a/meta/recipes-connectivity/connman/connman_1.38.bb
> b/meta/recipes-connectivity/connman/connman_1.39.bb
> similarity index 78%
> rename from meta/recipes-connectivity/connman/connman_1.38.bb
> rename to meta/recipes-connectivity/connman/connman_1.39.bb
> index 027c41e9af..df42e9ffb8 100644
> --- a/meta/recipes-connectivity/connman/connman_1.38.bb
> +++ b/meta/recipes-connectivity/connman/connman_1.39.bb
> @@ -9,8 +9,7 @@ SRC_URI =
> "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
>
> SRC_URI_append_libc-musl = "
> file://0002-resolve-musl-does-not-implement-res_ninit.patch"
>
> -SRC_URI[md5sum] = "1ed8745354c7254bdfd4def54833ee94"
> -SRC_URI[sha256sum] =
> "cb30aca97c2f79ccaed8802aa2909ac5100a3969de74c0af8a9d73b85fc4932b"
> +SRC_URI[sha256sum] =
> "9f62a7169b7491c670a1ff2e335b0d966308fb2f62e285c781105eb90f181af3"
>
> RRECOMMENDS_${PN} = "connman-conf"
> RCONFLICTS_${PN} = "networkmanager"
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147937):
https://lists.openembedded.org/g/openembedded-core/message/147937
Mute This Topic: https://lists.openembedded.org/mt/80524901/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
Hello Ray, On Wed, Feb 10, 2021 at 3:41 PM Ray Smith wrote: > > On Wed, Feb 10, 2021 at 1:26 PM Otavio Salvador > wrote: >> >> >> I didn't understand what you mean here. Could you elaborate this? >> > > If you try to build mesa with PACKAGECONFIG "egl gles dri" you get an error: > ../mesa-20.3.2/meson.build:144:4: ERROR: Problem encountered: building OpenGL > ES without OpenGL is not supported. > > This means that in practice you can't get a GLES-only build of mesa, so mesa > always provides OpenGL (ignoring Vulkan). But for an abstract graphics driver > that's not true - many drivers provide GLES but not OpenGL. I'd argue that > this is an implementation detail (and maybe a minor bug) of mesa. If mesa > internally requires code from its OpenGL support to build GLES, it should > silently include that if it's been configured for GLES-only. > > I only mention it to be clear that in general "GLES requires OpenGL" is not > true, even though mesa's build system enforces that. Should this be clarified with Mesa folks upfront? If you believe that this limitation is rather "artificial", then there has to be a proper explanation from Mesa developers why OGL is provided when OGLES-only is built. > > > -- Regards, Andrey. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147936): https://lists.openembedded.org/g/openembedded-core/message/147936 Mute This Topic: https://lists.openembedded.org/mt/80529198/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] security_flags.inc: Use -O with -D_FORTIFY_SOURCE
On Wed, Feb 10, 2021 at 1:57 AM Andre McCurdy wrote: > > On Wed, Feb 10, 2021 at 12:48 AM Mikko Rapeli wrote: > > > > Hi, > > > > On Tue, Feb 09, 2021 at 11:37:39PM -0800, Khem Raj wrote: > > > In this case -O will take effect sadly. and it seems to be that > > > autconf munges the compiler cmdline > > > while generating CFLAGS in generated Makefiles and appends the value > > > of -On coming from CC > > > variable last. > > > > > > I think right solution would be to add same -O as specified in > > > SELECTED_OPTIMIZATION so it remains > > > in sync always, I have sent a patch to ml. Could you test it out and > > > let me know if it works for you as well. > > > > Or let it go? A lot of recipes amend their own optimization flags and > > override > > distro wide optimization and other compiler flags. I once fixes all recipes > > in a project which were not obeying Os until buildhistory showed change in > > binary > > sizes... that was a lot of work for a PoC.. > > If the goal is to ensure that the optimisation flag from > FULL_OPTIMIZATION and the -D_FORTIFY_SOURCE flag from > lcl_maybe_fortify are always applied together then isn't the easiest > solution to move -D_FORTIFY_SOURCE out of lcl_maybe_fortify and into > FULL_OPTIMIZATION ? > The problem is that we insert the flags inconsistently and it depends on underlying build systems interpretation of these flags. e.g. We add D_FORTIFY_SOURCE to CC/CXX but -O to CFLAGS/CXXFLAGS many tests e.g. do not use CC and CFLAGS together, if we remove D_FORTIFY_SOURCE from CC/CXX then it does not get tested in configure tests but final compile uses it and cause miscompiles and this all is also need to keep in mind that we might have external toolchains which are compiled with its own set of options by default. Thats why we have to be explicit about these flags so they can be customized if needed. > Putting a separate optimisation flag in lcl_maybe_fortify and trying > to arrange for it not to clash with or override the one already in > FULL_OPTIMIZATION seems like an ugly solution, even if it can be made > to work. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147935): https://lists.openembedded.org/g/openembedded-core/message/147935 Mute This Topic: https://lists.openembedded.org/mt/80425803/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] security_flags.inc: Use -O with -D_FORTIFY_SOURCE
On Wed, Feb 10, 2021 at 12:48 AM Mikko Rapeli wrote: > > Hi, > > On Tue, Feb 09, 2021 at 11:37:39PM -0800, Khem Raj wrote: > > In this case -O will take effect sadly. and it seems to be that > > autconf munges the compiler cmdline > > while generating CFLAGS in generated Makefiles and appends the value > > of -On coming from CC > > variable last. > > > > I think right solution would be to add same -O as specified in > > SELECTED_OPTIMIZATION so it remains > > in sync always, I have sent a patch to ml. Could you test it out and > > let me know if it works for you as well. > > Or let it go? A lot of recipes amend their own optimization flags and override > distro wide optimization and other compiler flags. I once fixes all recipes > in a project which were not obeying Os until buildhistory showed change in > binary > sizes... that was a lot of work for a PoC.. > I think we need to solve this. I have seen many cases where configure tests silently fails due to these warnings and we don't necessarily notice it because configure just disables the failed part and the package might not fail to build We still are fine if a package is overriding these flags but we want to be consistent about what we pass. > Cheers, > > -Mikko > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147934): https://lists.openembedded.org/g/openembedded-core/message/147934 Mute This Topic: https://lists.openembedded.org/mt/80425803/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mpg123: Add support for FPU-less targets
On Wed, Feb 10, 2021 at 2:54 AM Robert Rosengren wrote: > > Actually, I used a MIPS-based device lacking FPU and ran simple > gstreamer/gst-play to test a mp3. A very non-scientific measurement on that > device using nmon moved from roughly 100% CPU load and stuttering audio to a > doable ~15-20% CPU load with the fixed point configuration. (of course all > such measurements depends heavily on audio latency, queues and so on of a > device hardware.) > OK thanks, this makes sense. > On 2/9/21 8:10 PM, Khem Raj wrote: > > is --with-cpu=generic_nofpu applicable for all soft fpu machines or > > just arm ? I wonder if it will improve or regress other nofpu > > machines. Do you have any data > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147933): https://lists.openembedded.org/g/openembedded-core/message/147933 Mute This Topic: https://lists.openembedded.org/mt/80504939/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Next steps for extrausers passwd-expire PR 63?
What are the next steps for this? https://github.com/openembedded/openembedded-core/pull/63 >This enhances extrausers with a new passwd-expire command that causes a local user's password to be expired as if the |passwd --expire| command was run, so the password needs to be changed on initial login. > Example: EXTRA_USERS_PARAMS += " useradd ... USER; passwd-expire USER;" This change works for me. Does it need more testing? Testing in configurations without a shadow file? - Joseph -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147932): https://lists.openembedded.org/g/openembedded-core/message/147932 Mute This Topic: https://lists.openembedded.org/mt/80537493/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
On Wed, Feb 10, 2021 at 3:15 PM akuster808 wrote: > > Did you run yocto-check-layer to ensure this passes? > > -armin > > I didn't, but I don't think it makes sense for this. At least, it fails for fundamental-looking reasons when run on oe-core/meta without my changes (assuming I'm running it correctly): ~/src/oe-core/build$ ../scripts/yocto-check-layer ../meta INFO: Detected layers: ERROR: meta: Can't be DISTRO and BSP type at the same time. Both conf/distro and conf/machine folders were found. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147931): https://lists.openembedded.org/g/openembedded-core/message/147931 Mute This Topic: https://lists.openembedded.org/mt/80529198/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] connman: update to 1.39
Changelog:
- Fix issue with scanning state synchronization and iwd.
- Fix issue with invalid key with 4-way handshake offloading.
- Fix issue with DNS proxy length checks to prevent buffer overflow.
- Fix issue with DHCP leaking stack data via uninitialized variable.
Signed-off-by: Oleksandr Kravchuk
---
.../connman/{connman_1.38.bb => connman_1.39.bb} | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
rename meta/recipes-connectivity/connman/{connman_1.38.bb => connman_1.39.bb}
(78%)
diff --git a/meta/recipes-connectivity/connman/connman_1.38.bb
b/meta/recipes-connectivity/connman/connman_1.39.bb
similarity index 78%
rename from meta/recipes-connectivity/connman/connman_1.38.bb
rename to meta/recipes-connectivity/connman/connman_1.39.bb
index 027c41e9af..df42e9ffb8 100644
--- a/meta/recipes-connectivity/connman/connman_1.38.bb
+++ b/meta/recipes-connectivity/connman/connman_1.39.bb
@@ -9,8 +9,7 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
SRC_URI_append_libc-musl = "
file://0002-resolve-musl-does-not-implement-res_ninit.patch"
-SRC_URI[md5sum] = "1ed8745354c7254bdfd4def54833ee94"
-SRC_URI[sha256sum] =
"cb30aca97c2f79ccaed8802aa2909ac5100a3969de74c0af8a9d73b85fc4932b"
+SRC_URI[sha256sum] =
"9f62a7169b7491c670a1ff2e335b0d966308fb2f62e285c781105eb90f181af3"
RRECOMMENDS_${PN} = "connman-conf"
RCONFLICTS_${PN} = "networkmanager"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147930):
https://lists.openembedded.org/g/openembedded-core/message/147930
Mute This Topic: https://lists.openembedded.org/mt/80524901/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
On 2/10/21 3:11 AM, Ray Smith wrote:
> Mesa doesn't _require_ either of these features of the distribution,
> it (conditionally) _provides_ them.
>
> This has a desirable side-effect of enabling a build of mesa that
> supports only OpenGL ES and EGL, without having the rest of the
> distribution think that full OpenGL is available.
>
> Without this, a distribution can't support different machines with
> (non-mesa) OpenGL ES/EGL-only drivers alongside mesa drivers, even
> when the distribution only needs OpenGL ES/EGL.
>
> (Note that currently mesa internally requires OpenGL support to be
> built in order for OpenGL ES support to be built, but this is a
> detail internal to mesa that should not be exposed to the wider
> build)
Did you run yocto-check-layer to ensure this passes?
-armin
> Signed-off-by: Ray Smith
> ---
> meta/recipes-graphics/mesa/mesa.inc | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index cb075a8b89..bdb978de95 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -44,12 +44,10 @@ PROVIDES = " \
> virtual/mesa \
> "
>
> -inherit meson pkgconfig python3native gettext features_check
> +inherit meson pkgconfig python3native gettext
>
> BBCLASSEXTEND = "native nativesdk"
>
> -ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan"
> -
> PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)}"
>
> export YOCTO_ALTERNATE_EXE_PATH =
> "${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE}/llvm-config"
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147929):
https://lists.openembedded.org/g/openembedded-core/message/147929
Mute This Topic: https://lists.openembedded.org/mt/80529198/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
On Wed, Feb 10, 2021 at 1:26 PM Otavio Salvador < otavio.salva...@ossystems.com.br> wrote: > > I didn't understand what you mean here. Could you elaborate this? > > If you try to build mesa with PACKAGECONFIG "egl gles dri" you get an error: ../mesa-20.3.2/meson.build:144:4: ERROR: Problem encountered: building OpenGL ES without OpenGL is not supported. This means that in practice you can't get a GLES-only build of mesa, so mesa always provides OpenGL (ignoring Vulkan). But for an abstract graphics driver that's not true - many drivers provide GLES but not OpenGL. I'd argue that this is an implementation detail (and maybe a minor bug) of mesa. If mesa internally requires code from its OpenGL support to build GLES, it should silently include that if it's been configured for GLES-only. I only mention it to be clear that in general "GLES requires OpenGL" is not true, even though mesa's build system enforces that. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147928): https://lists.openembedded.org/g/openembedded-core/message/147928 Mute This Topic: https://lists.openembedded.org/mt/80529198/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
Em qua., 10 de fev. de 2021 às 08:12, Ray Smith escreveu: > (Note that currently mesa internally requires OpenGL support to be > built in order for OpenGL ES support to be built, but this is a > detail internal to mesa that should not be exposed to the wider > build) > I didn't understand what you mean here. Could you elaborate this? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147927): https://lists.openembedded.org/g/openembedded-core/message/147927 Mute This Topic: https://lists.openembedded.org/mt/80529198/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH][gatesgarth 1/2] openssh: fix CVE-2020-14145
From: Lee Chee Yang
Signed-off-by: Lee Chee Yang
---
.../openssh/openssh/CVE-2020-14145.patch | 90 +++
.../openssh/openssh_8.3p1.bb | 1 +
2 files changed, 91 insertions(+)
create mode 100644
meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
diff --git a/meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
b/meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
new file mode 100644
index 00..0046ee1a51
--- /dev/null
+++ b/meta/recipes-connectivity/openssh/openssh/CVE-2020-14145.patch
@@ -0,0 +1,90 @@
+From b3855ff053f5078ec3d3c653cdaedefaa5fc362d Mon Sep 17 00:00:00 2001
+From: "d...@openbsd.org"
+Date: Fri, 18 Sep 2020 05:23:03 +
+Subject: [PATCH] upstream: tweak the client hostkey preference ordering
+ algorithm to
+
+prefer the default ordering if the user has a key that matches the
+best-preference default algorithm.
+
+feedback and ok markus@
+
+OpenBSD-Commit-ID: a92dd7d7520ddd95c0a16786a7519e6d0167d35f
+
+Upstream-Status: Backport
+[https://github.com/openssh/openssh-portable/commit/b3855ff053f5078ec3d3c653cdaedefaa5fc362d]
+CVE: CVE-2020-14145
+Signed-off-by: Chee Yang Lee
+
+---
+ sshconnect2.c | 41 ++---
+ 1 file changed, 37 insertions(+), 2 deletions(-)
+
+diff --git a/sshconnect2.c b/sshconnect2.c
+index 347e348c60..f64aae66af 100644
+--- a/sshconnect2.c
b/sshconnect2.c
+@@ -102,12 +102,25 @@ verify_host_key_callback(struct sshkey *hostkey, struct
ssh *ssh)
+ return 0;
+ }
+
++/* Returns the first item from a comma-separated algorithm list */
++static char *
++first_alg(const char *algs)
++{
++ char *ret, *cp;
++
++ ret = xstrdup(algs);
++ if ((cp = strchr(ret, ',')) != NULL)
++ *cp = '\0';
++ return ret;
++}
++
+ static char *
+ order_hostkeyalgs(char *host, struct sockaddr *hostaddr, u_short port)
+ {
+- char *oavail, *avail, *first, *last, *alg, *hostname, *ret;
++ char *oavail = NULL, *avail = NULL, *first = NULL, *last = NULL;
++ char *alg = NULL, *hostname = NULL, *ret = NULL, *best = NULL;
+ size_t maxlen;
+- struct hostkeys *hostkeys;
++ struct hostkeys *hostkeys = NULL;
+ int ktype;
+ u_int i;
+
+@@ -119,6 +132,26 @@ order_hostkeyalgs(char *host, struct sockaddr *hostaddr,
u_short port)
+ for (i = 0; i < options.num_system_hostfiles; i++)
+ load_hostkeys(hostkeys, hostname, options.system_hostfiles[i]);
+
++ /*
++ * If a plain public key exists that matches the type of the best
++ * preference HostkeyAlgorithms, then use the whole list as is.
++ * Note that we ignore whether the best preference algorithm is a
++ * certificate type, as sshconnect.c will downgrade certs to
++ * plain keys if necessary.
++ */
++ best = first_alg(options.hostkeyalgorithms);
++ if (lookup_key_in_hostkeys_by_type(hostkeys,
++ sshkey_type_plain(sshkey_type_from_name(best)), NULL)) {
++ debug3("%s: have matching best-preference key type %s, "
++ "using HostkeyAlgorithms verbatim", __func__, best);
++ ret = xstrdup(options.hostkeyalgorithms);
++ goto out;
++ }
++
++ /*
++ * Otherwise, prefer the host key algorithms that match known keys
++ * while keeping the ordering of HostkeyAlgorithms as much as possible.
++ */
+ oavail = avail = xstrdup(options.hostkeyalgorithms);
+ maxlen = strlen(avail) + 1;
+ first = xmalloc(maxlen);
+@@ -159,6 +192,8 @@ order_hostkeyalgs(char *host, struct sockaddr *hostaddr,
u_short port)
+ if (*first != '\0')
+ debug3("%s: prefer hostkeyalgs: %s", __func__, first);
+
++ out:
++ free(best);
+ free(first);
+ free(last);
+ free(hostname);
diff --git a/meta/recipes-connectivity/openssh/openssh_8.3p1.bb
b/meta/recipes-connectivity/openssh/openssh_8.3p1.bb
index 2aa1df20bd..70174c5197 100644
--- a/meta/recipes-connectivity/openssh/openssh_8.3p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_8.3p1.bb
@@ -24,6 +24,7 @@ SRC_URI =
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
file://fix-potential-signed-overflow-in-pointer-arithmatic.patch \
file://sshd_check_keys \
file://add-test-support-for-busybox.patch \
+ file://CVE-2020-14145.patch \
"
SRC_URI[sha256sum] =
"f2befbe0472fe7eb75d23340eb17531cb6b3aac24075e2066b41f814e12387b2"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147925):
https://lists.openembedded.org/g/openembedded-core/message/147925
Mute This Topic: https://lists.openembedded.org/mt/80530557/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH][gatesgarth 2/2] qemu: fix CVE-2020-29443 CVE-2020-35517
From: Lee Chee Yang
Signed-off-by: Lee Chee Yang
---
meta/recipes-devtools/qemu/qemu.inc | 2 +
.../qemu/qemu/CVE-2020-29443.patch| 46 +++
.../qemu/qemu/CVE-2020-35517.patch| 126 ++
3 files changed, 174 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-29443.patch
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-35517.patch
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 69b9a5f89e..97f110cde5 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -37,6 +37,8 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2020-25624.patch \
file://CVE-2020-25723.patch \
file://CVE-2020-28916.patch \
+ file://CVE-2020-35517.patch \
+ file://CVE-2020-29443.patch \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-29443.patch
b/meta/recipes-devtools/qemu/qemu/CVE-2020-29443.patch
new file mode 100644
index 00..5a3b99bb23
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-29443.patch
@@ -0,0 +1,46 @@
+
+m 813212288970c39b1800f63e83ac6e96588095c6 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini
+Date: Tue, 1 Dec 2020 13:09:26 +0100
+Subject: [PATCH] ide: atapi: assert that the buffer pointer is in range
+
+A case was reported where s->io_buffer_index can be out of range.
+The report skimped on the details but it seems to be triggered
+by s->lba == -1 on the READ/READ CD paths (e.g. by sending an
+ATAPI command with LBA = 0x). For now paper over it
+with assertions. The first one ensures that there is no overflow
+when incrementing s->io_buffer_index, the second checks for the
+buffer overrun.
+
+Note that the buffer overrun is only a read, so I am not sure
+if the assertion failure is actually less harmful than the overrun.
+
+Signed-off-by: Paolo Bonzini
+Message-id: 20201201120926.56559-1-pbonz...@redhat.com
+Reviewed-by: Kevin Wolf
+Signed-off-by: Peter Maydell
+
+Upstream-Status: Backport
[https://git.qemu.org/?p=qemu.git;a=patch;h=813212288970c39b1800f63e83ac6e96588095c6]
+CVE: CVE-2020-29443
+Signed-off-by: Chee Yang Lee
+
+---
+ hw/ide/atapi.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
+index 14a2b0b..e791578 100644
+--- a/hw/ide/atapi.c
b/hw/ide/atapi.c
+@@ -276,6 +276,8 @@ void ide_atapi_cmd_reply_end(IDEState *s)
+ s->packet_transfer_size -= size;
+ s->elementary_transfer_size -= size;
+ s->io_buffer_index += size;
++assert(size <= s->io_buffer_total_len);
++assert(s->io_buffer_index <= s->io_buffer_total_len);
+
+ /* Some adapters process PIO data right away. In that case, we need
+ * to avoid mutual recursion between ide_transfer_start
+--
+1.8.3.1
+
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-35517.patch
b/meta/recipes-devtools/qemu/qemu/CVE-2020-35517.patch
new file mode 100644
index 00..f818eb3bf5
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-35517.patch
@@ -0,0 +1,126 @@
+From ebf101955ce8f8d72fba103b5151115a4335de2c Mon Sep 17 00:00:00 2001
+From: Stefan Hajnoczi
+Date: Tue, 6 Oct 2020 10:58:26 +0100
+Subject: [PATCH] virtiofsd: avoid /proc/self/fd tempdir
+
+In order to prevent /proc/self/fd escapes a temporary directory is
+created where /proc/self/fd is bind-mounted. This doesn't work on
+read-only file systems.
+
+Avoid the temporary directory by bind-mounting /proc/self/fd over /proc.
+This does not affect other processes since we remounted / with MS_REC |
+MS_SLAVE. /proc must exist and virtiofsd does not use it so it's safe to
+do this.
+
+Path traversal can be tested with the following function:
+
+ static void test_proc_fd_escape(struct lo_data *lo)
+ {
+ int fd;
+ int level = 0;
+ ino_t last_ino = 0;
+
+ fd = lo->proc_self_fd;
+ for (;;) {
+ struct stat st;
+
+ if (fstat(fd, ) != 0) {
+ perror("fstat");
+ return;
+ }
+ if (last_ino && st.st_ino == last_ino) {
+ fprintf(stderr, "inode number unchanged, stopping\n");
+ return;
+ }
+ last_ino = st.st_ino;
+
+ fprintf(stderr, "Level %d dev %lu ino %lu\n", level,
+ (unsigned long)st.st_dev,
+ (unsigned long)last_ino);
+ fd = openat(fd, "..", O_PATH | O_DIRECTORY | O_NOFOLLOW);
+ level++;
+ }
+ }
+
+Before and after this patch only Level 0 is displayed. Without
+/proc/self/fd bind-mount protection it is possible to traverse parent
+directories.
+
+Fixes: 397ae982f4df4 ("virtiofsd: jail lo->proc_self_fd")
+Cc: Miklos Szeredi
+Cc: Jens Freimann
+Signed-off-by: Stefan Hajnoczi
+Message-Id: <20201006095826.59813-1-stefa...@redhat.com>
+Reviewed-by: Dr.
[OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
Mesa doesn't _require_ either of these features of the distribution,
it (conditionally) _provides_ them.
This has a desirable side-effect of enabling a build of mesa that
supports only OpenGL ES and EGL, without having the rest of the
distribution think that full OpenGL is available.
Without this, a distribution can't support different machines with
(non-mesa) OpenGL ES/EGL-only drivers alongside mesa drivers, even
when the distribution only needs OpenGL ES/EGL.
(Note that currently mesa internally requires OpenGL support to be
built in order for OpenGL ES support to be built, but this is a
detail internal to mesa that should not be exposed to the wider
build)
Signed-off-by: Ray Smith
---
meta/recipes-graphics/mesa/mesa.inc | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index cb075a8b89..bdb978de95 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -44,12 +44,10 @@ PROVIDES = " \
virtual/mesa \
"
-inherit meson pkgconfig python3native gettext features_check
+inherit meson pkgconfig python3native gettext
BBCLASSEXTEND = "native nativesdk"
-ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan"
-
PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)}"
export YOCTO_ALTERNATE_EXE_PATH =
"${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE}/llvm-config"
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147924):
https://lists.openembedded.org/g/openembedded-core/message/147924
Mute This Topic: https://lists.openembedded.org/mt/80529198/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mpg123: Add support for FPU-less targets
Actually, I used a MIPS-based device lacking FPU and ran simple gstreamer/gst-play to test a mp3. A very non-scientific measurement on that device using nmon moved from roughly 100% CPU load and stuttering audio to a doable ~15-20% CPU load with the fixed point configuration. (of course all such measurements depends heavily on audio latency, queues and so on of a device hardware.) On 2/9/21 8:10 PM, Khem Raj wrote: > is --with-cpu=generic_nofpu applicable for all soft fpu machines or > just arm ? I wonder if it will improve or regress other nofpu > machines. Do you have any data > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147923): https://lists.openembedded.org/g/openembedded-core/message/147923 Mute This Topic: https://lists.openembedded.org/mt/80504939/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] security_flags.inc: Use -O with -D_FORTIFY_SOURCE
On Wed, Feb 10, 2021 at 12:48 AM Mikko Rapeli wrote: > > Hi, > > On Tue, Feb 09, 2021 at 11:37:39PM -0800, Khem Raj wrote: > > In this case -O will take effect sadly. and it seems to be that > > autconf munges the compiler cmdline > > while generating CFLAGS in generated Makefiles and appends the value > > of -On coming from CC > > variable last. > > > > I think right solution would be to add same -O as specified in > > SELECTED_OPTIMIZATION so it remains > > in sync always, I have sent a patch to ml. Could you test it out and > > let me know if it works for you as well. > > Or let it go? A lot of recipes amend their own optimization flags and override > distro wide optimization and other compiler flags. I once fixes all recipes > in a project which were not obeying Os until buildhistory showed change in > binary > sizes... that was a lot of work for a PoC.. If the goal is to ensure that the optimisation flag from FULL_OPTIMIZATION and the -D_FORTIFY_SOURCE flag from lcl_maybe_fortify are always applied together then isn't the easiest solution to move -D_FORTIFY_SOURCE out of lcl_maybe_fortify and into FULL_OPTIMIZATION ? Putting a separate optimisation flag in lcl_maybe_fortify and trying to arrange for it not to clash with or override the one already in FULL_OPTIMIZATION seems like an ugly solution, even if it can be made to work. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147922): https://lists.openembedded.org/g/openembedded-core/message/147922 Mute This Topic: https://lists.openembedded.org/mt/80425803/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] security_flags.inc: Use -O with -D_FORTIFY_SOURCE
Hi, On Tue, Feb 09, 2021 at 11:37:39PM -0800, Khem Raj wrote: > In this case -O will take effect sadly. and it seems to be that > autconf munges the compiler cmdline > while generating CFLAGS in generated Makefiles and appends the value > of -On coming from CC > variable last. > > I think right solution would be to add same -O as specified in > SELECTED_OPTIMIZATION so it remains > in sync always, I have sent a patch to ml. Could you test it out and > let me know if it works for you as well. Or let it go? A lot of recipes amend their own optimization flags and override distro wide optimization and other compiler flags. I once fixes all recipes in a project which were not obeying Os until buildhistory showed change in binary sizes... that was a lot of work for a PoC.. Cheers, -Mikko -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147921): https://lists.openembedded.org/g/openembedded-core/message/147921 Mute This Topic: https://lists.openembedded.org/mt/80425803/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
