Re: [oe-core][PATCH] python3: add ${bindir}/python symlink

[Khem Raj]

On Wed, Nov 23, 2022 at 2:55 AM Alexander Kanavin
 wrote:
>
> On Wed, 23 Nov 2022 at 10:59, Ross Burton  wrote:
> > > The serious need is that we need to patch all the scripts that ask for 
> > > python to add a 3 to it. And there will be more of these going forward, 
> > > not less. I’d rather just always have python available. Not a problem 
> > > worth deliberating over to be honest.
> >
> > But as per PEP 0384, /usr/bin/python could be python2, or not there at all. 
> >  Software should use python3.
>
> But would anyone pay attention to the PEP when writing new scripts?

they should be pointed to PEP and I hope python tutors teach it from day 1.

If
> /usr/bin/python is available by default, as it is already on Fedora,

There perhaps is a reason for that in Fedora, but it is in conflict
with what PEP0384 is saying

> and probably will be on Debian (in testing/sid there is no choice
> between 2 and 3 anymore - 2 is gone, and that clears the road to have
> python->python3 installed by default), then it's not unreasonable to
> have the script use that. I wouldn't want to know or care about
> python's historical baggage. That's why I'm saying we're going to see
> more upstreams that are just having #!/usr/bin/python and don't give a
> damn, even when you point it out to them.
>

If you want to ignore the baggage then know that there is no
/usr/bin/python anymore.

> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173724): 
https://lists.openembedded.org/g/openembedded-core/message/173724
Mute This Topic: https://lists.openembedded.org/mt/95156228/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] python3: add ${bindir}/python symlink

[Khem Raj]

On Sun, Nov 20, 2022 at 3:56 PM Alexander Kanavin 
wrote:

> Python community has no plans for python4 whatsoever. Anything but gentle
> and steady evolution won’t be well received.
>
>
> https://www.techrepublic.com/article/programming-languages-why-python-4-0-will-probably-never-arrive-according-to-its-creator/
>

Good news article although it does not say that python3 and python are
analogous and python package does not explicitly install python binary or
symlink either so it’s left up to how distros want to presume it. If we
want to do that then it would be prudent to see what other distributions
are doing in this regard. So we are not alone in case trouble arises

>
>
> Alex
>
> On Mon 21. Nov 2022 at 0.17, Khem Raj  wrote:
>
>>
>>
>> On Sun, Nov 20, 2022 at 9:52 AM Markus Volk  wrote:
>>
>>> Currently /usr/bin/python is provided by the python2 package. If python2
>>> is not installed, the built image lacks a provider for it.
>>> This results in failed scripts when using '/usr/bin/python' shebang.
>>>
>>> This patch adds a /usr/bin/python symlink for python3 to fix this issue.
>>> For images containing python2 and python3, the do_rootfs task will fail
>>> because now both of them provide the same file.
>>> To allow this corner case, a DISTRO_FEATURE 'python2' has been
>>> introduced which,
>>> if set, will prevent python3 from creating the symlink.
>>>
>>> The link is created with relative path because using an absolute path
>>> would fail
>>> for native and nativesdk.
>>
>>
>> What happens if and when python4 comes ?
>> This might get us into same mess we had migrating python2 to 3
>>
>>
>>>
>>> Signed-off-by: Markus Volk 
>>> ---
>>>  meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
>>>  meta/recipes-devtools/python/python3_3.11.0.bb | 4 
>>>  2 files changed, 5 insertions(+)
>>>
>>> diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
>>> b/meta/recipes-devtools/python/python3/python3-manifest.json
>>> index 64203cf0fc..7b6f509a45 100644
>>> --- a/meta/recipes-devtools/python/python3/python3-manifest.json
>>> +++ b/meta/recipes-devtools/python/python3/python3-manifest.json
>>> @@ -203,6 +203,7 @@
>>>  "files": [
>>>  "${bindir}/python${PYTHON_MAJMIN}",
>>>  "${bindir}/python${PYTHON_MAJMIN}.real",
>>> +"${bindir}/python",
>>>  "${bindir}/python3",
>>>  "${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
>>>  "${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
>>> diff --git a/meta/recipes-devtools/python/python3_3.11.0.bb
>>> b/meta/recipes-devtools/python/python3_3.11.0.bb
>>> index 92a1f69320..18b631f79d 100644
>>> --- a/meta/recipes-devtools/python/python3_3.11.0.bb
>>> +++ b/meta/recipes-devtools/python/python3_3.11.0.bb
>>> @@ -144,6 +144,7 @@ do_install:prepend() {
>>>
>>>  do_install:append:class-target() {
>>>  oe_multilib_header python${PYTHON_MAJMIN}/pyconfig.h
>>> +${@bb.utils.contains('DISTRO_FEATURES', 'python2', '', 'ln -sf
>>> ./python3 ${D}${bindir}/python', d)}
>>>  }
>>>
>>>  do_install:append:class-native() {
>>> @@ -156,6 +157,7 @@ do_install:append:class-native() {
>>>  # (these often end up too long for the #! parser in the kernel
>>> as the
>>>  # buffer is 128 bytes long).
>>>  ln -s python3-native/python3 ${D}${bindir}/nativepython3
>>> +${@bb.utils.contains('DISTRO_FEATURES', 'python2', '', 'ln -sf
>>> ./python3-native/python3 ${D}${bindir}/nativepython', d)}
>>>
>>>  # Remove the opt-1.pyc and opt-2.pyc files. There are over
>>> 3,000 of them
>>>  # and the overhead in each recipe-sysroot-native isn't worth
>>> it, particularly
>>> @@ -213,6 +215,7 @@ do_install:append() {
>>>  }
>>>
>>>  do_install:append:class-nativesdk () {
>>> +${@bb.utils.contains('DISTRO_FEATURES', 'python2', '', 'ln -sf
>>> ./python3 ${D}${bindir}/python', d)}
>>>  # Make sure we use /usr/bin/env python
>>>  for PYTHSCRIPT in `grep -rIl ${bindir}/python ${D}${bindir}`; do
>>>   sed -i -e '1s|^#!.*|#!/usr/bin/env python3|' $PYTHSCRIPT
>>> @@ -376,6 +379,7 @@ RRECOMMENDS:${PN}-crypt:append:class-nativesdk =

Re: [oe-core][PATCH] python3: add ${bindir}/python symlink

[Khem Raj]

On Sun, Nov 20, 2022 at 9:52 AM Markus Volk  wrote:

> Currently /usr/bin/python is provided by the python2 package. If python2
> is not installed, the built image lacks a provider for it.
> This results in failed scripts when using '/usr/bin/python' shebang.
>
> This patch adds a /usr/bin/python symlink for python3 to fix this issue.
> For images containing python2 and python3, the do_rootfs task will fail
> because now both of them provide the same file.
> To allow this corner case, a DISTRO_FEATURE 'python2' has been introduced
> which,
> if set, will prevent python3 from creating the symlink.
>
> The link is created with relative path because using an absolute path
> would fail
> for native and nativesdk.


What happens if and when python4 comes ?
This might get us into same mess we had migrating python2 to 3


>
> Signed-off-by: Markus Volk 
> ---
>  meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
>  meta/recipes-devtools/python/python3_3.11.0.bb | 4 
>  2 files changed, 5 insertions(+)
>
> diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
> b/meta/recipes-devtools/python/python3/python3-manifest.json
> index 64203cf0fc..7b6f509a45 100644
> --- a/meta/recipes-devtools/python/python3/python3-manifest.json
> +++ b/meta/recipes-devtools/python/python3/python3-manifest.json
> @@ -203,6 +203,7 @@
>  "files": [
>  "${bindir}/python${PYTHON_MAJMIN}",
>  "${bindir}/python${PYTHON_MAJMIN}.real",
> +"${bindir}/python",
>  "${bindir}/python3",
>  "${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
>  "${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
> diff --git a/meta/recipes-devtools/python/python3_3.11.0.bb
> b/meta/recipes-devtools/python/python3_3.11.0.bb
> index 92a1f69320..18b631f79d 100644
> --- a/meta/recipes-devtools/python/python3_3.11.0.bb
> +++ b/meta/recipes-devtools/python/python3_3.11.0.bb
> @@ -144,6 +144,7 @@ do_install:prepend() {
>
>  do_install:append:class-target() {
>  oe_multilib_header python${PYTHON_MAJMIN}/pyconfig.h
> +${@bb.utils.contains('DISTRO_FEATURES', 'python2', '', 'ln -sf
> ./python3 ${D}${bindir}/python', d)}
>  }
>
>  do_install:append:class-native() {
> @@ -156,6 +157,7 @@ do_install:append:class-native() {
>  # (these often end up too long for the #! parser in the kernel as
> the
>  # buffer is 128 bytes long).
>  ln -s python3-native/python3 ${D}${bindir}/nativepython3
> +${@bb.utils.contains('DISTRO_FEATURES', 'python2', '', 'ln -sf
> ./python3-native/python3 ${D}${bindir}/nativepython', d)}
>
>  # Remove the opt-1.pyc and opt-2.pyc files. There are over 3,000
> of them
>  # and the overhead in each recipe-sysroot-native isn't worth it,
> particularly
> @@ -213,6 +215,7 @@ do_install:append() {
>  }
>
>  do_install:append:class-nativesdk () {
> +${@bb.utils.contains('DISTRO_FEATURES', 'python2', '', 'ln -sf
> ./python3 ${D}${bindir}/python', d)}
>  # Make sure we use /usr/bin/env python
>  for PYTHSCRIPT in `grep -rIl ${bindir}/python ${D}${bindir}`; do
>   sed -i -e '1s|^#!.*|#!/usr/bin/env python3|' $PYTHSCRIPT
> @@ -376,6 +379,7 @@ RRECOMMENDS:${PN}-crypt:append:class-nativesdk = "
> ${MLPREFIX}openssl ${MLPREFIX
>
>  # For historical reasons PN is empty and provided by python3-modules
>  FILES:${PN} = ""
> +RPROVIDES:${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'python2', '',
> '${bindir}/python', d)}"
>  RPROVIDES:${PN}-modules = "${PN}"
>
>  FILES:${PN}-pydoc += "${bindir}/pydoc${PYTHON_MAJMIN} ${bindir}/pydoc3"
> --
> 2.34.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173642): 
https://lists.openembedded.org/g/openembedded-core/message/173642
Mute This Topic: https://lists.openembedded.org/mt/95156228/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] qemu-helper-native: Correctly pass program name as argv[0]

[Khem Raj]

On Wed, Nov 16, 2022 at 10:49 AM Joshua Watt  wrote:
>
> The previous version of this wasn't correctly passing the program name
> as argv[0], and was also over-complicated anyway because argv[] is
> guaranteed to be terminated with a NULL pointer, so it can be passed
> directly to the execv'd process without needing to be copied.
>
> Signed-off-by: Joshua Watt 
> ---
>  .../qemu/qemu-helper/qemu-oe-bridge-helper.c  | 15 ---
>  1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/meta/recipes-devtools/qemu/qemu-helper/qemu-oe-bridge-helper.c 
> b/meta/recipes-devtools/qemu/qemu-helper/qemu-oe-bridge-helper.c
> index cadf2a012ac..9434e1d2699 100644
> --- a/meta/recipes-devtools/qemu/qemu-helper/qemu-oe-bridge-helper.c
> +++ b/meta/recipes-devtools/qemu/qemu-helper/qemu-oe-bridge-helper.c
> @@ -8,6 +8,7 @@
>
>  #include 
>  #include 
> +#include 

why do we need stdlib.h header ?

>
>  void try_program(char const* path, char** args) {
>  if (access(path, X_OK) == 0) {
> @@ -18,22 +19,14 @@ void try_program(char const* path, char** args) {
>  int main(int argc, char** argv) {
>  char* var;
>
> -/* Copy arguments so that they are a NULL terminated list, skipping 
> argv[0]
> - * since it is this program name */
> -char** args = malloc(argc * sizeof(char*));
> -for (int i = 0; i < argc - 1; i++) {
> -args[i] = argv[i + 1];
> -}
> -args[argc - 1] = NULL;
> -
>  var = getenv("QEMU_BRIDGE_HELPER");
>  if (var && var[0] != '\0') {
> -execvp(var, args);
> +execvp(var, argv);
>  return 1;
>  }
>
> -try_program("/usr/libexec/qemu-bridge-helper", args);
> -try_program("/usr/lib/qemu/qemu-bridge-helper", args);
> +try_program("/usr/libexec/qemu-bridge-helper", argv);
> +try_program("/usr/lib/qemu/qemu-bridge-helper", argv);
>
>  fprintf(stderr, "No bridge helper found\n");
>  return 1;
> --
> 2.33.0
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173395): 
https://lists.openembedded.org/g/openembedded-core/message/173395
Mute This Topic: https://lists.openembedded.org/mt/95073277/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] resolvconf: make it work

[Khem Raj]

On Tue, Nov 15, 2022 at 5:45 AM Chen Qi  wrote:
>
> The current resolvconf does not work. Make it work with the
> following changes.
> 1. Install normalize-resolvconf, which is used by resolvconf.
> 2. Add dependencies sed, coreutils, util-linux-flock.
>util-linux-flock is needed by our busybox does not support '-w'
>by default. coreutils is needed by the busybox's readlink does
>not support '-m'. sed is needed because we want to avoid package
>QA issue complaining sed is needed by no one provides it.

Can we avoid dependency on coreutils ? maybe check why -m is needed
and perhaps just use
absolute link.

>
> Signed-off-by: Chen Qi 
> ---
>  meta/recipes-connectivity/resolvconf/resolvconf_1.91.bb | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-connectivity/resolvconf/resolvconf_1.91.bb 
> b/meta/recipes-connectivity/resolvconf/resolvconf_1.91.bb
> index 94fd2c1a70..3bf5ec6c32 100644
> --- a/meta/recipes-connectivity/resolvconf/resolvconf_1.91.bb
> +++ b/meta/recipes-connectivity/resolvconf/resolvconf_1.91.bb
> @@ -9,7 +9,7 @@ LICENSE = "GPL-2.0-or-later"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b"
>  AUTHOR = "Thomas Hood"
>  HOMEPAGE = "http://packages.debian.org/resolvconf;
> -RDEPENDS:${PN} = "bash"
> +RDEPENDS:${PN} = "bash sed coreutils util-linux-flock"
>
>  SRC_URI = 
> "git://salsa.debian.org/debian/resolvconf.git;protocol=https;branch=unstable \
> file://99_resolvconf \
> @@ -39,12 +39,14 @@ do_install () {
> fi
> install -d ${D}${base_libdir}/${BPN}
> install -d ${D}${sysconfdir}/${BPN}
> +   install -d ${D}${nonarch_base_libdir}/${BPN}
> ln -snf ${localstatedir}/run/${BPN} ${D}${sysconfdir}/${BPN}/run
> install -d ${D}${sysconfdir} ${D}${base_sbindir}
> install -d ${D}${mandir}/man8 ${D}${docdir}/${P}
> cp -pPR etc/resolvconf ${D}${sysconfdir}/
> chown -R root:root ${D}${sysconfdir}/
> install -m 0755 bin/resolvconf ${D}${base_sbindir}/
> +   install -m 0755 bin/normalize-resolvconf 
> ${D}${nonarch_base_libdir}/${BPN}
> install -m 0755 bin/list-records ${D}${base_libdir}/${BPN}
> install -d ${D}/${sysconfdir}/network/if-up.d
> install -m 0755 debian/resolvconf.000resolvconf.if-up 
> ${D}/${sysconfdir}/network/if-up.d/000resolvconf
> @@ -64,4 +66,4 @@ pkg_postinst:${PN} () {
> fi
>  }
>
> -FILES:${PN} += "${base_libdir}/${BPN}"
> +FILES:${PN} += "${base_libdir}/${BPN} ${nonarch_base_libdir}/${BPN}"
> --
> 2.17.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173380): 
https://lists.openembedded.org/g/openembedded-core/message/173380
Mute This Topic: https://lists.openembedded.org/mt/95042786/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] [meta-oe] [PATCH 2/2] Support for building on RISCV

[Khem Raj]

Looks ok to me

On Sat, Nov 12, 2022 at 1:13 AM cp0613  wrote:

> From: Chen Pei 
>
> Signed-off-by: Chen Pei 
> ---
>  meta/recipes-devtools/meson/meson_0.64.0.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-devtools/meson/meson_0.64.0.bb
> b/meta/recipes-devtools/meson/meson_0.64.0.bb
> index 84c3c84515..c8ef8a23c5 100644
> --- a/meta/recipes-devtools/meson/meson_0.64.0.bb
> +++ b/meta/recipes-devtools/meson/meson_0.64.0.bb
> @@ -67,6 +67,8 @@ def generate_native_link_template(d):
>  loader = 'ld-linux-aarch64.so.1'
>  elif 'ppc64le' in build_arch:
>  loader = 'ld64.so.2'
> +elif 'riscv64' in build_arch:
> +loader = 'ld-linux-riscv64-lp64d.so.1'
>
>  if loader:
>  val +=
> ['-Wl,--dynamic-linker=@{OECORE_NATIVE_SYSROOT}${base_libdir_native}/' +
> loader]
> --
> 2.25.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173164): 
https://lists.openembedded.org/g/openembedded-core/message/173164
Mute This Topic: https://lists.openembedded.org/mt/94977045/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 1/3] spirv-tools: Correctly set the prefix in exported cmake packages

[Khem Raj]

On Thu, Nov 10, 2022 at 12:42 PM Jordan Crouse via
lists.openembedded.org 
wrote:
>
> spirv-tools exports Cmake packages.  When they are installed the
> INTERFACE_LINK_LIBRARIES variable is not correctly updated to use
> _IMPORT_PREFIX like the other variables. This may have something to do with
> the path to the sysroot being different than the source path.
>
> The existing recipe recognizes that the sysroot path made it through to the
> install and tries to get rid of it, but this just ends up with dependent
> tools looking in vain for /usr/lib/librt.so.
>
> Replace the INTERFACE_LINK_LIBRARIES value in SPIRV-ToolsTarget.cmake with
> "${IMPORT_PREFIX}/lib".
>
> Signed-off-by: Jordan Crouse 
> ---
>
>  meta/recipes-graphics/spir/spirv-tools_1.3.231.1.bb | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-graphics/spir/spirv-tools_1.3.231.1.bb 
> b/meta/recipes-graphics/spir/spirv-tools_1.3.231.1.bb
> index ea47796543..fdc9c9225a 100644
> --- a/meta/recipes-graphics/spir/spirv-tools_1.3.231.1.bb
> +++ b/meta/recipes-graphics/spir/spirv-tools_1.3.231.1.bb
> @@ -10,6 +10,8 @@ LIC_FILES_CHKSUM = 
> "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
>  SRCREV = "eb0a36633d2acf4de82588504f951ad0f2cecacb"
>  SRC_URI = 
> "git://github.com/KhronosGroup/SPIRV-Tools.git;branch=master;protocol=https"
>  PE = "1"
> +PR = "r1"

We no longer bump the PR manually. So this is not needed.

> +
>  UPSTREAM_CHECK_GITTAGREGEX = "sdk-(?P\d+(\.\d+)+)"
>  S = "${WORKDIR}/git"
>
> @@ -25,9 +27,10 @@ EXTRA_OECMAKE += "\
>  "
>
>  do_install:append:class-target() {
> -# reproducibility: remove build host path
> +# Properly set _IMPORT_PREFIX in INTERFACE_LINK_LIBRARIES so that 
> dependent
> +# tools can find the right library
>  sed -i ${D}${libdir}/cmake/SPIRV-Tools/SPIRV-ToolsTarget.cmake \
> --e 's:${STAGING_DIR_HOST}::g'
> +-e 's:INTERFACE_LINK_LIBRARIES.*$:INTERFACE_LINK_LIBRARIES 
> "\$\{_IMPORT_PREFIX\}/lib":'
>  }
>
>  # all the libraries are unversioned, so don't pack it on PN-dev
> --
> 2.37.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173109): 
https://lists.openembedded.org/g/openembedded-core/message/173109
Mute This Topic: https://lists.openembedded.org/mt/94945230/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 46/48] python3: use the standard shell version of python3-config

[Khem Raj]

I am seeing a bunch of failures perhaps related but not sure

https://errors.yoctoproject.org/Errors/Build/154610/

On Tue, Nov 8, 2022 at 2:59 PM Richard Purdie
 wrote:
>
> On Mon, 2022-11-07 at 15:55 +0100, Alexander Kanavin wrote:
> >
> > +SYSROOT_PREPROCESS_FUNCS:append:class-target = " 
> > provide_target_config_script"
> > +SYSROOT_PREPROCESS_FUNCS:append:class-nativesdk = " 
> > provide_target_config_script"
> > +
> > +provide_target_config_script() {
> > +install -d ${SYSROOT_DESTDIR}${bindir}/
> > +install ${D}/${bindir}/python3-config ${SYSROOT_DESTDIR}${bindir}/
> > +install ${D}/${bindir}/python${PYTHON_MAJMIN}-config 
> > ${SYSROOT_DESTDIR}${bindir}/
> > +}
> > +
> > +
> >  SSTATE_SCAN_FILES += "Makefile _sysconfigdata.py"
> >  SSTATE_HASHEQUIV_FILEMAP = " \
> >  populate_sysroot:*/lib*/python3*/_sysconfigdata*.py:${TMPDIR} \
>
> This made me wonder if we shouldn't have a better way of handling this.
> I was wondering if we should have a sysroot_stage_file function (like
> sysroot_stage_dir) and then we could do something like:
>
> sysroot_stage_all:append() {
> sysroot_stage_file ${D}/${bindir}/python3-config 
> ${SYSROOT_DESTDIR}/${bindir}/python3-config
> }
>
> Note that the sysroot code plays with hardlinks for efficiency, I
> appreciate one file doesn't really matter though.
>
> I was hoping we could have just added to SYSROOT_DIRS but that does
> only handle dirs, not files.
>
> Cheers,
>
> Richard
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173010): 
https://lists.openembedded.org/g/openembedded-core/message/173010
Mute This Topic: https://lists.openembedded.org/mt/94867622/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 v3] systemd: Fix 252 release build on musl

[Khem Raj]

Signed-off-by: Khem Raj 
Cc: Luca Boccassi 
---
v2: Replace the utmp patch with an upstream backport 
v3: Drop unrelated recipe changes

 .../0001-Adjust-for-musl-headers.patch|  84 +-
 c-Use-net-if.h-for-getting-IFF_LOOP.patch |  27 +++
 ...trerror-is-assumed-to-be-GNU-specifi.patch |  42 +
 ...-test-utmp.c-only-if-UTMP-is-enabled.patch |  44 +
 .../0002-Add-sys-stat.h-for-S_IFDIR.patch |   4 +-
 ...k-parse_printf_format-implementation.patch |  22 +--
 ...missing.h-check-for-missing-strndupa.patch | 158 ++
 ...OB_BRACE-and-GLOB_ALTDIRFUNC-is-not-.patch |  29 ++--
 ...10-Use-uintmax_t-for-handling-rlim_t.patch |  14 +-
 ...T_SYMLINK_NOFOLLOW-flag-to-faccessat.patch |  14 +-
 ...patible-basename-for-non-glibc-syste.patch |   8 +-
 ...uffering-when-writing-to-oom_score_a.patch |   4 +-
 ...compliant-strerror_r-from-GNU-specif.patch |  22 ++-
 ...-not-disable-buffer-in-writing-files.patch | 100 ---
 .../systemd/0026-Handle-missing-gshadow.patch |  14 +-
 meta/recipes-core/systemd/systemd_252.bb  |   5 +-
 16 files changed, 218 insertions(+), 373 deletions(-)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-networkd-ipv4acd.c-Use-net-if.h-for-getting-IFF_LOOP.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-test-bus-error-strerror-is-assumed-to-be-GNU-specifi.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-test-compile-test-utmp.c-only-if-UTMP-is-enabled.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch 
b/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch
index bce1ca4563..6496280dda 100644
--- a/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch
+++ b/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch
@@ -47,8 +47,6 @@ Signed-off-by: Khem Raj 
  src/udev/udev-builtin-net_id.c| 2 +-
  37 files changed, 44 insertions(+), 42 deletions(-)
 
-diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
-index b346a50d78..7884d4c1cd 100644
 --- a/src/libsystemd-network/sd-dhcp6-client.c
 +++ b/src/libsystemd-network/sd-dhcp6-client.c
 @@ -5,7 +5,7 @@
@@ -60,8 +58,6 @@ index b346a50d78..7884d4c1cd 100644
  #include 
  
  #include "sd-dhcp6-client.h"
-diff --git a/src/network/netdev/bareudp.c b/src/network/netdev/bareudp.c
-index 8ff0eb1360..7e06b8d57d 100644
 --- a/src/network/netdev/bareudp.c
 +++ b/src/network/netdev/bareudp.c
 @@ -2,7 +2,7 @@
@@ -73,8 +69,6 @@ index 8ff0eb1360..7e06b8d57d 100644
  
  #include "bareudp.h"
  #include "netlink-util.h"
-diff --git a/src/network/netdev/batadv.c b/src/network/netdev/batadv.c
-index 15f3aee3a6..ec76428436 100644
 --- a/src/network/netdev/batadv.c
 +++ b/src/network/netdev/batadv.c
 @@ -3,7 +3,7 @@
@@ -86,8 +80,6 @@ index 15f3aee3a6..ec76428436 100644
  
  #include "batadv.h"
  #include "fileio.h"
-diff --git a/src/network/netdev/bond.c b/src/network/netdev/bond.c
-index 5d94aa1d68..4e379a326d 100644
 --- a/src/network/netdev/bond.c
 +++ b/src/network/netdev/bond.c
 @@ -1,7 +1,7 @@
@@ -99,8 +91,6 @@ index 5d94aa1d68..4e379a326d 100644
  
  #include "alloc-util.h"
  #include "bond.h"
-diff --git a/src/network/netdev/bridge.c b/src/network/netdev/bridge.c
-index b974f2ae0a..9a5f18d556 100644
 --- a/src/network/netdev/bridge.c
 +++ b/src/network/netdev/bridge.c
 @@ -2,7 +2,7 @@
@@ -112,8 +102,6 @@ index b974f2ae0a..9a5f18d556 100644
  #include 
  
  #include "bridge.h"
-diff --git a/src/network/netdev/dummy.c b/src/network/netdev/dummy.c
-index 00df1d2787..77b506b422 100644
 --- a/src/network/netdev/dummy.c
 +++ b/src/network/netdev/dummy.c
 @@ -1,6 +1,6 @@
@@ -124,8 +112,6 @@ index 00df1d2787..77b506b422 100644
  
  #include "dummy.h"
  
-diff --git a/src/network/netdev/geneve.c b/src/network/netdev/geneve.c
-index 224c17e979..fb79cc13f6 100644
 --- a/src/network/netdev/geneve.c
 +++ b/src/network/netdev/geneve.c
 @@ -2,7 +2,7 @@
@@ -137,8 +123,6 @@ index 224c17e979..fb79cc13f6 100644
  
  #include "alloc-util.h"
  #include "conf-parser.h"
-diff --git a/src/network/netdev/ifb.c b/src/network/netdev/ifb.c
-index d7ff44cb9e..e037629ae4 100644
 --- a/src/network/netdev/ifb.c
 +++ b/src/network/netdev/ifb.c
 @@ -1,7 +1,7 @@
@@ -150,8 +134,6 @@ index d7ff44cb9e..e037629ae4 100644
  
  #include "ifb.h"
  
-diff --git a/src/network/netdev/ipoib.c b/src/network/netdev/ipoib.c
-index e0ff9e8c62..ab085c1f6d 100644
 --- a/src/network/netdev/ipoib.c
 +++ b/src/network/netdev/ipoib.c
 @@ -1,6 +1,6 @@
@@ -162,8 +144,6 @@ index e0ff9e8c62..ab085c1f6d 100644
  #include 
  
  #include "ipoib.h"
-diff --git a/src/network/netdev/ipvlan.c b/src/network/netdev/ipvlan.c
-index d15766cd7b..60728b4f94 100644
 --- a/src/network/netdev/ipvlan.c
 +++ b/src/network/netdev/ipvlan.c
 @@ -2,7 +2,7 @@
@@ -175,8 +155,6 @@ index

Re: [OE-core] [PATCH v2] systemd: Fix 252 release build on musl

[Khem Raj]

On Tue, Nov 8, 2022 at 2:39 PM Richard Purdie
 wrote:
>
> On Tue, 2022-11-08 at 13:55 -0800, Khem Raj wrote:
> > Signed-off-by: Khem Raj 
> > Cc: Luca Boccassi 
> > ---
> > v2: Replace the utmp patch with an upstream backport
> >
> >  .../0001-Adjust-for-musl-headers.patch|  84 +-
> >  c-Use-net-if.h-for-getting-IFF_LOOP.patch |  27 +++
> >  ...trerror-is-assumed-to-be-GNU-specifi.patch |  42 +
> >  ...-test-utmp.c-only-if-UTMP-is-enabled.patch |  44 +
> >  .../0002-Add-sys-stat.h-for-S_IFDIR.patch |   4 +-
> >  ...k-parse_printf_format-implementation.patch |  22 +--
> >  ...missing.h-check-for-missing-strndupa.patch | 158 ++
> >  ...OB_BRACE-and-GLOB_ALTDIRFUNC-is-not-.patch |  29 ++--
> >  ...10-Use-uintmax_t-for-handling-rlim_t.patch |  14 +-
> >  ...T_SYMLINK_NOFOLLOW-flag-to-faccessat.patch |  14 +-
> >  ...patible-basename-for-non-glibc-syste.patch |   8 +-
> >  ...uffering-when-writing-to-oom_score_a.patch |   4 +-
> >  ...compliant-strerror_r-from-GNU-specif.patch |  22 ++-
> >  ...-not-disable-buffer-in-writing-files.patch | 100 ---
> >  .../systemd/0026-Handle-missing-gshadow.patch |  14 +-
> >  meta/recipes-core/systemd/systemd_252.bb  |   5 +-
> >  .../btrfs-tools/btrfs-tools_6.0.bb|   3 +
> >  .../recipes-multimedia/alsa/alsa-lib_1.2.8.bb |   2 +
>
> Should a systemd fix be patching alsa-lib or btrfs-tools for large file
> support? :)

oh I should have separated these changes. Thanks for spotting.

>
> Cheers,
>
> Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173004): 
https://lists.openembedded.org/g/openembedded-core/message/173004
Mute This Topic: https://lists.openembedded.org/mt/94900869/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 v2] systemd: Fix 252 release build on musl

[Khem Raj]

Signed-off-by: Khem Raj 
Cc: Luca Boccassi 
---
v2: Replace the utmp patch with an upstream backport

 .../0001-Adjust-for-musl-headers.patch|  84 +-
 c-Use-net-if.h-for-getting-IFF_LOOP.patch |  27 +++
 ...trerror-is-assumed-to-be-GNU-specifi.patch |  42 +
 ...-test-utmp.c-only-if-UTMP-is-enabled.patch |  44 +
 .../0002-Add-sys-stat.h-for-S_IFDIR.patch |   4 +-
 ...k-parse_printf_format-implementation.patch |  22 +--
 ...missing.h-check-for-missing-strndupa.patch | 158 ++
 ...OB_BRACE-and-GLOB_ALTDIRFUNC-is-not-.patch |  29 ++--
 ...10-Use-uintmax_t-for-handling-rlim_t.patch |  14 +-
 ...T_SYMLINK_NOFOLLOW-flag-to-faccessat.patch |  14 +-
 ...patible-basename-for-non-glibc-syste.patch |   8 +-
 ...uffering-when-writing-to-oom_score_a.patch |   4 +-
 ...compliant-strerror_r-from-GNU-specif.patch |  22 ++-
 ...-not-disable-buffer-in-writing-files.patch | 100 ---
 .../systemd/0026-Handle-missing-gshadow.patch |  14 +-
 meta/recipes-core/systemd/systemd_252.bb  |   5 +-
 .../btrfs-tools/btrfs-tools_6.0.bb|   3 +
 .../recipes-multimedia/alsa/alsa-lib_1.2.8.bb |   2 +
 18 files changed, 223 insertions(+), 373 deletions(-)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-networkd-ipv4acd.c-Use-net-if.h-for-getting-IFF_LOOP.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-test-bus-error-strerror-is-assumed-to-be-GNU-specifi.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-test-compile-test-utmp.c-only-if-UTMP-is-enabled.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch 
b/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch
index bce1ca4563..6496280dda 100644
--- a/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch
+++ b/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch
@@ -47,8 +47,6 @@ Signed-off-by: Khem Raj 
  src/udev/udev-builtin-net_id.c| 2 +-
  37 files changed, 44 insertions(+), 42 deletions(-)
 
-diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
-index b346a50d78..7884d4c1cd 100644
 --- a/src/libsystemd-network/sd-dhcp6-client.c
 +++ b/src/libsystemd-network/sd-dhcp6-client.c
 @@ -5,7 +5,7 @@
@@ -60,8 +58,6 @@ index b346a50d78..7884d4c1cd 100644
  #include 
  
  #include "sd-dhcp6-client.h"
-diff --git a/src/network/netdev/bareudp.c b/src/network/netdev/bareudp.c
-index 8ff0eb1360..7e06b8d57d 100644
 --- a/src/network/netdev/bareudp.c
 +++ b/src/network/netdev/bareudp.c
 @@ -2,7 +2,7 @@
@@ -73,8 +69,6 @@ index 8ff0eb1360..7e06b8d57d 100644
  
  #include "bareudp.h"
  #include "netlink-util.h"
-diff --git a/src/network/netdev/batadv.c b/src/network/netdev/batadv.c
-index 15f3aee3a6..ec76428436 100644
 --- a/src/network/netdev/batadv.c
 +++ b/src/network/netdev/batadv.c
 @@ -3,7 +3,7 @@
@@ -86,8 +80,6 @@ index 15f3aee3a6..ec76428436 100644
  
  #include "batadv.h"
  #include "fileio.h"
-diff --git a/src/network/netdev/bond.c b/src/network/netdev/bond.c
-index 5d94aa1d68..4e379a326d 100644
 --- a/src/network/netdev/bond.c
 +++ b/src/network/netdev/bond.c
 @@ -1,7 +1,7 @@
@@ -99,8 +91,6 @@ index 5d94aa1d68..4e379a326d 100644
  
  #include "alloc-util.h"
  #include "bond.h"
-diff --git a/src/network/netdev/bridge.c b/src/network/netdev/bridge.c
-index b974f2ae0a..9a5f18d556 100644
 --- a/src/network/netdev/bridge.c
 +++ b/src/network/netdev/bridge.c
 @@ -2,7 +2,7 @@
@@ -112,8 +102,6 @@ index b974f2ae0a..9a5f18d556 100644
  #include 
  
  #include "bridge.h"
-diff --git a/src/network/netdev/dummy.c b/src/network/netdev/dummy.c
-index 00df1d2787..77b506b422 100644
 --- a/src/network/netdev/dummy.c
 +++ b/src/network/netdev/dummy.c
 @@ -1,6 +1,6 @@
@@ -124,8 +112,6 @@ index 00df1d2787..77b506b422 100644
  
  #include "dummy.h"
  
-diff --git a/src/network/netdev/geneve.c b/src/network/netdev/geneve.c
-index 224c17e979..fb79cc13f6 100644
 --- a/src/network/netdev/geneve.c
 +++ b/src/network/netdev/geneve.c
 @@ -2,7 +2,7 @@
@@ -137,8 +123,6 @@ index 224c17e979..fb79cc13f6 100644
  
  #include "alloc-util.h"
  #include "conf-parser.h"
-diff --git a/src/network/netdev/ifb.c b/src/network/netdev/ifb.c
-index d7ff44cb9e..e037629ae4 100644
 --- a/src/network/netdev/ifb.c
 +++ b/src/network/netdev/ifb.c
 @@ -1,7 +1,7 @@
@@ -150,8 +134,6 @@ index d7ff44cb9e..e037629ae4 100644
  
  #include "ifb.h"
  
-diff --git a/src/network/netdev/ipoib.c b/src/network/netdev/ipoib.c
-index e0ff9e8c62..ab085c1f6d 100644
 --- a/src/network/netdev/ipoib.c
 +++ b/src/network/netdev/ipoib.c
 @@ -1,6 +1,6 @@
@@ -162,8 +144,6 @@ index e0ff9e8c62..ab085c1f6d 100644
  #include 
  
  #include "ipoib.h"
-diff --git a/src/network/netdev/ipvlan.c b/src/network/netdev/ipvlan.c
-index d15766cd7b..60728b4f94 100644
 --- a/src/network/netdev/ipvlan

[OE-core] [PATCH] systemd: Fix 252 release build on musl

[Khem Raj]

Signed-off-by: Khem Raj 
Cc: Luca Boccassi 
---
 .../0001-Adjust-for-musl-headers.patch|  84 +-
 c-Use-net-if.h-for-getting-IFF_LOOP.patch |  27 +++
 ...trerror-is-assumed-to-be-GNU-specifi.patch |  42 +
 ...-Guard-the-testcase-with-ENABLE_UTMP.patch |  40 +
 .../0002-Add-sys-stat.h-for-S_IFDIR.patch |   4 +-
 ...k-parse_printf_format-implementation.patch |  22 +--
 ...missing.h-check-for-missing-strndupa.patch | 158 ++
 ...OB_BRACE-and-GLOB_ALTDIRFUNC-is-not-.patch |  29 ++--
 ...10-Use-uintmax_t-for-handling-rlim_t.patch |  14 +-
 ...T_SYMLINK_NOFOLLOW-flag-to-faccessat.patch |  14 +-
 ...patible-basename-for-non-glibc-syste.patch |   8 +-
 ...uffering-when-writing-to-oom_score_a.patch |   4 +-
 ...compliant-strerror_r-from-GNU-specif.patch |  22 ++-
 ...-not-disable-buffer-in-writing-files.patch | 100 ---
 .../systemd/0026-Handle-missing-gshadow.patch |  14 +-
 meta/recipes-core/systemd/systemd_252.bb  |   5 +-
 .../btrfs-tools/btrfs-tools_6.0.bb|   3 +
 .../recipes-multimedia/alsa/alsa-lib_1.2.8.bb |   2 +
 18 files changed, 219 insertions(+), 373 deletions(-)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-networkd-ipv4acd.c-Use-net-if.h-for-getting-IFF_LOOP.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-test-bus-error-strerror-is-assumed-to-be-GNU-specifi.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-test-utmp-Guard-the-testcase-with-ENABLE_UTMP.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch 
b/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch
index bce1ca4563..6496280dda 100644
--- a/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch
+++ b/meta/recipes-core/systemd/systemd/0001-Adjust-for-musl-headers.patch
@@ -47,8 +47,6 @@ Signed-off-by: Khem Raj 
  src/udev/udev-builtin-net_id.c| 2 +-
  37 files changed, 44 insertions(+), 42 deletions(-)
 
-diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
-index b346a50d78..7884d4c1cd 100644
 --- a/src/libsystemd-network/sd-dhcp6-client.c
 +++ b/src/libsystemd-network/sd-dhcp6-client.c
 @@ -5,7 +5,7 @@
@@ -60,8 +58,6 @@ index b346a50d78..7884d4c1cd 100644
  #include 
  
  #include "sd-dhcp6-client.h"
-diff --git a/src/network/netdev/bareudp.c b/src/network/netdev/bareudp.c
-index 8ff0eb1360..7e06b8d57d 100644
 --- a/src/network/netdev/bareudp.c
 +++ b/src/network/netdev/bareudp.c
 @@ -2,7 +2,7 @@
@@ -73,8 +69,6 @@ index 8ff0eb1360..7e06b8d57d 100644
  
  #include "bareudp.h"
  #include "netlink-util.h"
-diff --git a/src/network/netdev/batadv.c b/src/network/netdev/batadv.c
-index 15f3aee3a6..ec76428436 100644
 --- a/src/network/netdev/batadv.c
 +++ b/src/network/netdev/batadv.c
 @@ -3,7 +3,7 @@
@@ -86,8 +80,6 @@ index 15f3aee3a6..ec76428436 100644
  
  #include "batadv.h"
  #include "fileio.h"
-diff --git a/src/network/netdev/bond.c b/src/network/netdev/bond.c
-index 5d94aa1d68..4e379a326d 100644
 --- a/src/network/netdev/bond.c
 +++ b/src/network/netdev/bond.c
 @@ -1,7 +1,7 @@
@@ -99,8 +91,6 @@ index 5d94aa1d68..4e379a326d 100644
  
  #include "alloc-util.h"
  #include "bond.h"
-diff --git a/src/network/netdev/bridge.c b/src/network/netdev/bridge.c
-index b974f2ae0a..9a5f18d556 100644
 --- a/src/network/netdev/bridge.c
 +++ b/src/network/netdev/bridge.c
 @@ -2,7 +2,7 @@
@@ -112,8 +102,6 @@ index b974f2ae0a..9a5f18d556 100644
  #include 
  
  #include "bridge.h"
-diff --git a/src/network/netdev/dummy.c b/src/network/netdev/dummy.c
-index 00df1d2787..77b506b422 100644
 --- a/src/network/netdev/dummy.c
 +++ b/src/network/netdev/dummy.c
 @@ -1,6 +1,6 @@
@@ -124,8 +112,6 @@ index 00df1d2787..77b506b422 100644
  
  #include "dummy.h"
  
-diff --git a/src/network/netdev/geneve.c b/src/network/netdev/geneve.c
-index 224c17e979..fb79cc13f6 100644
 --- a/src/network/netdev/geneve.c
 +++ b/src/network/netdev/geneve.c
 @@ -2,7 +2,7 @@
@@ -137,8 +123,6 @@ index 224c17e979..fb79cc13f6 100644
  
  #include "alloc-util.h"
  #include "conf-parser.h"
-diff --git a/src/network/netdev/ifb.c b/src/network/netdev/ifb.c
-index d7ff44cb9e..e037629ae4 100644
 --- a/src/network/netdev/ifb.c
 +++ b/src/network/netdev/ifb.c
 @@ -1,7 +1,7 @@
@@ -150,8 +134,6 @@ index d7ff44cb9e..e037629ae4 100644
  
  #include "ifb.h"
  
-diff --git a/src/network/netdev/ipoib.c b/src/network/netdev/ipoib.c
-index e0ff9e8c62..ab085c1f6d 100644
 --- a/src/network/netdev/ipoib.c
 +++ b/src/network/netdev/ipoib.c
 @@ -1,6 +1,6 @@
@@ -162,8 +144,6 @@ index e0ff9e8c62..ab085c1f6d 100644
  #include 
  
  #include "ipoib.h"
-diff --git a/src/network/netdev/ipvlan.c b/src/network/netdev/ipvlan.c
-index d15766cd7b..60728b4f94 100644
 --- a/src/network/netdev/ipvlan.c
 +++ b/src/network/netdev/ipvlan.c
 @@ -2,7 +2,7 @@
@@ 

Re: [OE-core] [RFC PATCH 2/3] kbd: Disable 64 bit time with 32 bit glibc

[Khem Raj]

On Tue, Nov 8, 2022 at 1:14 AM Alexander Kanavin  wrote:
>
> We do build for 32 bit arm targets, so is this seen only in specific
> circumstances? What are they?

Its when 64bit time_t is used with glibc on 32bit architectures. So
far we do not do that explicitly, with musl time_t is always 64bit

>
> Alex
>
> On Tue, 8 Nov 2022 at 01:09, Niko Mauno via lists.openembedded.org
>  wrote:
> >
> > For now add exemption in order to avoid following failure during
> > do_compile()
> >
> >   | 
> > .../build/tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/kbd/2.5.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/12.2.0/ld:.libs/libtswrap.ver:2:
> >  syntax error in VERSION script
> >   | collect2: error: ld returned 1 exit status
> >
> > Signed-off-by: Niko Mauno 
> > ---
> >  meta/recipes-core/kbd/kbd_2.5.1.bb | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/recipes-core/kbd/kbd_2.5.1.bb 
> > b/meta/recipes-core/kbd/kbd_2.5.1.bb
> > index aa3ab6e121..b623aecd36 100644
> > --- a/meta/recipes-core/kbd/kbd_2.5.1.bb
> > +++ b/meta/recipes-core/kbd/kbd_2.5.1.bb
> > @@ -18,6 +18,9 @@ SRC_URI = 
> > "${KERNELORG_MIRROR}/linux/utils/${BPN}/${BP}.tar.xz \
> >
> >  SRC_URI[sha256sum] = 
> > "ccdf452387a6380973d2927363e9cbb939fa2068915a6f937ff9d24522024683"
> >
> > +# Compiling 64 bit time for 32 bit host is broken
> > +GLIBC_64BIT_TIME_CPPFLAGS = ""
> > +
> >  PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)} \
> >"
> >
> > --
> > 2.36.1
> >
> >
> >
> >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172979): 
https://lists.openembedded.org/g/openembedded-core/message/172979
Mute This Topic: https://lists.openembedded.org/mt/94880633/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] [RFC PATCH 1/3] Try to ensure 64 bit time on 32 bit glibcful hosts

[Khem Raj]

On Tue, Nov 8, 2022 at 2:56 AM Ola x Nilsson  wrote:
>
>
> I'm working on the same thing, but I put GLIBC_64BIT_TIME_CPPFLAGS in
> TARGET_CC_ARCH instead to make sure they applied everywhere.
>
> I'd be interested to hear what others think is the best place to put
> these flags.
>
> I'm also looking at QA tests to make sure that no application or shared
> object is still using 32bit time or file functions from glibc.

Perhaps another thing is that it might be good to control it via a
distro feature.

>
> /Ola
>
> On Tue, Nov 08 2022, Niko Mauno via lists.openembedded.org wrote:
>
> > Add default C Preprocessor flags that ensure Y2038 compatible 64 bit
> > time on 32 bit host applications when glibc is used. Prerequisites
> > are glibc version 2.34 or newer and Linux kernel version 5.1 or newer.
> >
> > Example of impact on 32 bit 'qemuarm' machine running
> > core-image-minimal. Before this change:
> >
> >   root@qemuarm:~# /bin/busybox date
> >   Sun Nov  6 06:09:39 UTC 2022
> >   root@qemuarm:~# /sbin/hwclock.util-linux -w
> >   root@qemuarm:~# /sbin/hwclock.util-linux
> >   2022-11-06 06:09:49.994249+00:00
> >   root@qemuarm:~# /bin/busybox date -s 2040-01-01
> >   date: invalid date '2040-01-01'
> >   root@qemuarm:~# /bin/date.coreutils -s 2040-01-01
> >   Sun Jan  1 00:00:00 UTC 2040
> >   root@qemuarm:~# /sbin/hwclock.util-linux -w
> >   root@qemuarm:~# /sbin/hwclock.util-linux
> >   1931-03-04 06:26:23.00+00:00
> >   root@qemuarm:~#
> >
> > After this change:
> >
> >   root@qemuarm:~# /bin/busybox date
> >   Sun Nov  6 06:02:20 UTC 2022
> >   root@qemuarm:~# /sbin/hwclock.util-linux -w
> >   root@qemuarm:~# /sbin/hwclock.util-linux
> >   2022-11-06 06:02:27.989730+00:00
> >   root@qemuarm:~# /bin/busybox date -s 2040-01-01
> >   Sun Jan  1 00:00:00 UTC 2040
> >   root@qemuarm:~# /sbin/hwclock.util-linux -w
> >   root@qemuarm:~# /sbin/hwclock.util-linux
> >   2040-01-01 00:00:20.992954+00:00
> >   root@qemuarm:~#
> >
> > From here on, the adding of new flags can be disabled on recipe or
> > global level by resetting the value of associated variable containing
> > the CPPFLAGS specific for 64 bit time
> >
> >   GLIBC_64BIT_TIME_CPPFLAGS = ""
> >
> > which can be useful e.g. when working around failure to compile a
> > component due to lack of 64 bit time support on 32 bit build in the
> > component's source code.
> >
> > Signed-off-by: Niko Mauno 
> > ---
> >  meta/conf/distro/include/tclibc-glibc.inc| 3 +++
> >  meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb | 2 ++
> >  meta/recipes-devtools/pseudo/pseudo_git.bb   | 2 ++
> >  3 files changed, 7 insertions(+)
> >
> > diff --git a/meta/conf/distro/include/tclibc-glibc.inc 
> > b/meta/conf/distro/include/tclibc-glibc.inc
> > index f48d16939e..95770298e9 100644
> > --- a/meta/conf/distro/include/tclibc-glibc.inc
> > +++ b/meta/conf/distro/include/tclibc-glibc.inc
> > @@ -17,6 +17,9 @@ PREFERRED_PROVIDER_virtual/crypt ?= "libxcrypt"
> >
> >  CXXFLAGS += "-fvisibility-inlines-hidden"
> >
> > +GLIBC_64BIT_TIME_CPPFLAGS = "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"
> > +TARGET_CPPFLAGS += "${GLIBC_64BIT_TIME_CPPFLAGS}"
> > +
> >  LIBC_DEPENDENCIES = "\
> >glibc \
> >glibc-dbg \
> > diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb 
> > b/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
> > index 8bda2ccad6..b3fafa0ea4 100644
> > --- a/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
> > +++ b/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
> > @@ -5,3 +5,5 @@ require gcc-sanitizers.inc
> >  # sanitizer_linux.s:5749: Error: lo register required -- `ldr ip,[sp],#8'
> >  ARM_INSTRUCTION_SET:armv4 = "arm"
> >  ARM_INSTRUCTION_SET:armv5 = "arm"
> > +
> > +GLIBC_64BIT_TIME_CPPFLAGS = ""
> > diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
> > b/meta/recipes-devtools/pseudo/pseudo_git.bb
> > index c34580b4ff..7734d0fbb0 100644
> > --- a/meta/recipes-devtools/pseudo/pseudo_git.bb
> > +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
> > @@ -19,3 +19,5 @@ PV = "1.9.0+git${SRCPV}"
> >
> >  # error: use of undeclared identifier '_STAT_VER'
> >  COMPATIBLE_HOST:libc-musl = 'null'
> > +
> > +GLIBC_64BIT_TIME_CPPFLAGS = ""
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172978): 
https://lists.openembedded.org/g/openembedded-core/message/172978
Mute This Topic: https://lists.openembedded.org/mt/94880624/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] [RFC PATCH 1/3] Try to ensure 64 bit time on 32 bit glibcful hosts

[Khem Raj]

On Mon, Nov 7, 2022 at 4:09 PM Niko Mauno via lists.openembedded.org
 wrote:
>
> Add default C Preprocessor flags that ensure Y2038 compatible 64 bit
> time on 32 bit host applications when glibc is used. Prerequisites
> are glibc version 2.34 or newer and Linux kernel version 5.1 or newer.
>
> Example of impact on 32 bit 'qemuarm' machine running
> core-image-minimal. Before this change:
>
>   root@qemuarm:~# /bin/busybox date
>   Sun Nov  6 06:09:39 UTC 2022
>   root@qemuarm:~# /sbin/hwclock.util-linux -w
>   root@qemuarm:~# /sbin/hwclock.util-linux
>   2022-11-06 06:09:49.994249+00:00
>   root@qemuarm:~# /bin/busybox date -s 2040-01-01
>   date: invalid date '2040-01-01'
>   root@qemuarm:~# /bin/date.coreutils -s 2040-01-01
>   Sun Jan  1 00:00:00 UTC 2040
>   root@qemuarm:~# /sbin/hwclock.util-linux -w
>   root@qemuarm:~# /sbin/hwclock.util-linux
>   1931-03-04 06:26:23.00+00:00
>   root@qemuarm:~#
>
> After this change:
>
>   root@qemuarm:~# /bin/busybox date
>   Sun Nov  6 06:02:20 UTC 2022
>   root@qemuarm:~# /sbin/hwclock.util-linux -w
>   root@qemuarm:~# /sbin/hwclock.util-linux
>   2022-11-06 06:02:27.989730+00:00
>   root@qemuarm:~# /bin/busybox date -s 2040-01-01
>   Sun Jan  1 00:00:00 UTC 2040
>   root@qemuarm:~# /sbin/hwclock.util-linux -w
>   root@qemuarm:~# /sbin/hwclock.util-linux
>   2040-01-01 00:00:20.992954+00:00
>   root@qemuarm:~#
>
> From here on, the adding of new flags can be disabled on recipe or
> global level by resetting the value of associated variable containing
> the CPPFLAGS specific for 64 bit time
>
>   GLIBC_64BIT_TIME_CPPFLAGS = ""
>
> which can be useful e.g. when working around failure to compile a
> component due to lack of 64 bit time support on 32 bit build in the
> component's source code.
>
> Signed-off-by: Niko Mauno 
> ---
>  meta/conf/distro/include/tclibc-glibc.inc| 3 +++
>  meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb | 2 ++
>  meta/recipes-devtools/pseudo/pseudo_git.bb   | 2 ++
>  3 files changed, 7 insertions(+)
>
> diff --git a/meta/conf/distro/include/tclibc-glibc.inc 
> b/meta/conf/distro/include/tclibc-glibc.inc
> index f48d16939e..95770298e9 100644
> --- a/meta/conf/distro/include/tclibc-glibc.inc
> +++ b/meta/conf/distro/include/tclibc-glibc.inc
> @@ -17,6 +17,9 @@ PREFERRED_PROVIDER_virtual/crypt ?= "libxcrypt"
>
>  CXXFLAGS += "-fvisibility-inlines-hidden"
>
> +GLIBC_64BIT_TIME_CPPFLAGS = "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"
> +TARGET_CPPFLAGS += "${GLIBC_64BIT_TIME_CPPFLAGS}"

We only need it for 32bit systems and not for 64bit systems. So
perhaps we need it for only 32bit systems.

> +
>  LIBC_DEPENDENCIES = "\
>  glibc \
>  glibc-dbg \
> diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb 
> b/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
> index 8bda2ccad6..b3fafa0ea4 100644
> --- a/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
> +++ b/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
> @@ -5,3 +5,5 @@ require gcc-sanitizers.inc
>  # sanitizer_linux.s:5749: Error: lo register required -- `ldr ip,[sp],#8'
>  ARM_INSTRUCTION_SET:armv4 = "arm"
>  ARM_INSTRUCTION_SET:armv5 = "arm"
> +
> +GLIBC_64BIT_TIME_CPPFLAGS = ""
> diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
> b/meta/recipes-devtools/pseudo/pseudo_git.bb
> index c34580b4ff..7734d0fbb0 100644
> --- a/meta/recipes-devtools/pseudo/pseudo_git.bb
> +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
> @@ -19,3 +19,5 @@ PV = "1.9.0+git${SRCPV}"
>
>  # error: use of undeclared identifier '_STAT_VER'
>  COMPATIBLE_HOST:libc-musl = 'null'
> +
> +GLIBC_64BIT_TIME_CPPFLAGS = ""
> --
> 2.36.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172946): 
https://lists.openembedded.org/g/openembedded-core/message/172946
Mute This Topic: https://lists.openembedded.org/mt/94880624/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 44/48] selftest: add a copy of previous mtd-utils version to meta-selftest

[Khem Raj]

On Mon, Nov 7, 2022 at 6:56 AM Alexander Kanavin  wrote:
>
> The latest version update eliminated all custom patches, and the selftest
> expects them.
>

interesting, is it used for testing the patching mechanism during selftest ?
in that case it might be possible to use package which has a sticky
patch instead.
we can avoid maintaining another recipe.

> Signed-off-by: Alexander Kanavin 
> ---
>  ...used-linux-fs.h-header-from-includes.patch | 31 
>  .../mtd/mtd-utils-selftest_git.bb | 77 +++
>  meta/lib/oeqa/selftest/cases/devtool.py   |  4 +-
>  3 files changed, 110 insertions(+), 2 deletions(-)
>  create mode 100644 
> meta-selftest/recipes-devtools/mtd/mtd-utils-selftest/0001-tests-Remove-unused-linux-fs.h-header-from-includes.patch
>  create mode 100644 
> meta-selftest/recipes-devtools/mtd/mtd-utils-selftest_git.bb
>
> diff --git 
> a/meta-selftest/recipes-devtools/mtd/mtd-utils-selftest/0001-tests-Remove-unused-linux-fs.h-header-from-includes.patch
>  
> b/meta-selftest/recipes-devtools/mtd/mtd-utils-selftest/0001-tests-Remove-unused-linux-fs.h-header-from-includes.patch
> new file mode 100644
> index 00..73d4a8475f
> --- /dev/null
> +++ 
> b/meta-selftest/recipes-devtools/mtd/mtd-utils-selftest/0001-tests-Remove-unused-linux-fs.h-header-from-includes.patch
> @@ -0,0 +1,31 @@
> +From 6fb10bd18488ed84776675bc1b2982800a51d839 Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Sat, 6 Aug 2022 20:14:38 -0700
> +Subject: [mtd-utils][PATCH] tests: Remove unused linux/fs.h header from 
> includes
> +
> +This header is not needed, moreover it includes linux/mount.h which is
> +now in conflict[1] with glibc provided sys/mount.h from glibc 2.36 onwards
> +
> +[1] https://sourceware.org/glibc/wiki/Release/2.36
> +
> +Upstream-Status: Submitted 
> [https://lists.infradead.org/pipermail/linux-mtd/2022-August/094667.html]
> +Signed-off-by: Khem Raj 
> +---
> + tests/fs-tests/lib/tests.c | 1 -
> + 1 file changed, 1 deletion(-)
> +
> +diff --git a/tests/fs-tests/lib/tests.c b/tests/fs-tests/lib/tests.c
> +index d1a2e0c..3db0426 100644
> +--- a/tests/fs-tests/lib/tests.c
>  b/tests/fs-tests/lib/tests.c
> +@@ -35,7 +35,6 @@
> + #include 
> + #include 
> + #include 
> +-#include 
> + #include 
> +
> + #include "tests.h"
> +--
> +2.37.1
> +
> diff --git a/meta-selftest/recipes-devtools/mtd/mtd-utils-selftest_git.bb 
> b/meta-selftest/recipes-devtools/mtd/mtd-utils-selftest_git.bb
> new file mode 100644
> index 00..ca2141c972
> --- /dev/null
> +++ b/meta-selftest/recipes-devtools/mtd/mtd-utils-selftest_git.bb
> @@ -0,0 +1,77 @@
> +SUMMARY = "Tools for managing memory technology devices"
> +HOMEPAGE = "http://www.linux-mtd.infradead.org/;
> +DESCRIPTION = "mtd-utils tool is a generic Linux subsystem for memory 
> devices, especially Flash devices."
> +SECTION = "base"
> +LICENSE = "GPL-2.0-or-later"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
> +
> file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c"
> +
> +inherit autotools pkgconfig update-alternatives
> +
> +DEPENDS = "zlib e2fsprogs util-linux"
> +RDEPENDS:mtd-utils-tests += "bash"
> +
> +PV = "2.1.4"
> +
> +SRCREV = "c7f1bfa44a84d02061787e2f6093df5cc40b9f5c"
> +SRC_URI = "git://git.infradead.org/mtd-utils.git;branch=master \
> +   
> file://0001-tests-Remove-unused-linux-fs.h-header-from-includes.patch \
> +   "
> +
> +S = "${WORKDIR}/git"
> +
> +# xattr support creates an additional compile-time dependency on acl because
> +# the sys/acl.h header is needed. libacl is not needed and thus enabling 
> xattr
> +# regardless whether acl is enabled or disabled in the distro should be okay.
> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'xattr', d)} lzo 
> jffs ubifs"
> +PACKAGECONFIG[lzo] = "--with-lzo,--without-lzo,lzo"
> +PACKAGECONFIG[xattr] = "--with-xattr,--without-xattr,acl"
> +PACKAGECONFIG[crypto] = "--with-crypto,--without-crypto,openssl"
> +PACKAGECONFIG[jffs] = "--with-jffs,--without-jffs"
> +PACKAGECONFIG[ubifs] = "--with-ubifs,--without-ubifs"
> +PACKAGECONFIG[zstd] = "--with-zstd,--without-zstd,zstd"
> +
> +CPPFLAGS:append:riscv64  = " -pthread -D_REENTRANT"
> +
> +EXTRA_OEMAKE = "'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'CFLAGS=${CFLAGS} 
> ${@bb.utils.contains('PACKAGECONFIG', 'xattr', '', '-DWITHOUT_XATTR', d)} 
> -I${S}/include' 'BUILDDIR=${S}'"
&

Re: [OE-core] [PATCH 35/48] netbase: upgrade 6.3 -> 6.4

[Khem Raj]

On Mon, Nov 7, 2022 at 6:56 AM Alexander Kanavin  wrote:
>
> License-Update: formatting, copyright years
>
> Signed-off-by: Alexander Kanavin 
> ---
>  .../recipes-core/netbase/{netbase_6.3.bb => netbase_6.4.bb} | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>  rename meta/recipes-core/netbase/{netbase_6.3.bb => netbase_6.4.bb} (77%)
>
> diff --git a/meta/recipes-core/netbase/netbase_6.3.bb 
> b/meta/recipes-core/netbase/netbase_6.4.bb
> similarity index 77%
> rename from meta/recipes-core/netbase/netbase_6.3.bb
> rename to meta/recipes-core/netbase/netbase_6.4.bb
> index bec6498cdd..5a448a4b91 100644
> --- a/meta/recipes-core/netbase/netbase_6.3.bb
> +++ b/meta/recipes-core/netbase/netbase_6.4.bb
> @@ -3,14 +3,14 @@ DESCRIPTION = "This package provides the necessary 
> infrastructure for basic TCP/
>  HOMEPAGE = "http://packages.debian.org/netbase;
>  SECTION = "base"
>  LICENSE = "GPL-2.0-only"
> -LIC_FILES_CHKSUM = 
> "file://debian/copyright;md5=3dd6192d306f582dee7687da3d8748ab"
> +LIC_FILES_CHKSUM = 
> "file://debian/copyright;md5=78dd2c7c6f487348e4a0092c17a19d42"
>  PE = "1"
>
>  SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz"
>
>  inherit allarch
>
> -SRC_URI[sha256sum] = 
> "7c42a6a1cafa0c64103c71cab6431fc8613179b2449a1a00e55e3584e860d81c"
> +SRC_URI[sha256sum] = 
> "fa6621826ff1150e581bd90bc3c8a4ecafe5df90404f207db6dcdf2c75f26ad7"
>
>  UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/n/netbase/"
>
> @@ -21,3 +21,5 @@ do_install () {
> install -m 0644 ${S}/etc/services ${D}${sysconfdir}/services
> install -m 0644 ${S}/etc/ethertypes ${D}${sysconfdir}/ethertypes
>  }
> +
> +S = "${WORKDIR}/netbase"

Is there a change in path name in the new tarball?

> --
> 2.30.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172928): 
https://lists.openembedded.org/g/openembedded-core/message/172928
Mute This Topic: https://lists.openembedded.org/mt/94867607/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] webkitgtk: use libsoup-3.0 by default

[Khem Raj]

On Sat, Nov 5, 2022 at 9:44 AM Markus Volk  wrote:
>
> Some Gnome projects have stopped  supporting libsoup-2.4. Therefore, switch 
> to libsoup-3.0.
> This would unblock the update of geary or gnome-online-accounts, which would 
> otherwise
> fail like this:
>
> | Run-time dependency webkit2gtk-4.1 found: NO (tried pkgconfig)
> |
> | ../git/meson.build:70:0: ERROR: Dependency "webkit2gtk-4.1" not found, 
> tried pkgconfig
>

There is also a break overved in some meta-oe packages see

https://errors.yoctoproject.org/Errors/Build/154536/
Perhaps minio is not related but I have not looked too closely.

> Signed-off-by: Markus Volk 
> ---
>  meta/recipes-sato/webkit/webkitgtk_2.36.7.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.36.7.bb 
> b/meta/recipes-sato/webkit/webkitgtk_2.36.7.bb
> index 76b119c9c7..f3e1adee70 100644
> --- a/meta/recipes-sato/webkit/webkitgtk_2.36.7.bb
> +++ b/meta/recipes-sato/webkit/webkitgtk_2.36.7.bb
> @@ -43,7 +43,7 @@ DEPENDS = " \
>gstreamer1.0-plugins-base \
>"
>
> -PACKAGECONFIG_SOUP ?= "soup2"
> +PACKAGECONFIG_SOUP ?= "soup3"
>  PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'systemd wayland 
> x11', d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 
> 'webgl opengl', '', d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', 'webgl 
> gles2', d)} \
> --
> 2.34.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172925): 
https://lists.openembedded.org/g/openembedded-core/message/172925
Mute This Topic: https://lists.openembedded.org/mt/94829885/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][master][kirkstone][PATCH V2] rng-tools: Add Arm aarch64 CPU specific configuration to address excessive CPU usage on startup

[Khem Raj]

On Sun, Nov 6, 2022 at 5:21 PM Xiangyu Chen  wrote:
>
>
> On 11/1/22 09:48, Xiangyu Chen wrote:
> > With the default jitter options aarch64 CPU-based devices typically 
> > experience continuous
> > high CPU utilisation for several minutes after rngd starts.
> >
> > Accoring to the rng-tools issue #150[1] and comments[2],in order to address 
> > this,
> > the following configuration changes have been made, those configurations
> > also can be found on Alpine Linux[3]:
> >
> > - reduce the number of threads used to 1 in total, rather than 1 per core.
> > - reduce the buffer size from 16535 to 4133 which reduces the time taken
> >to fill the buffer (and so reduces the duration of CPU load).
> >
> > [1] https://github.com/nhorman/rng-tools/issues/150
> > [2] https://github.com/nhorman/rng-tools/issues/150#issuecomment-953079212
> > [3] https://git.alpinelinux.org/aports/tree/main/rng-tools/rngd.confd-arm
> >
> > Signed-off-by: Xiangyu Chen 
> > ---
> > Changes in V2:
> >*put the aarch64 specific default file in 
> > meta/recipes-support/rng-tools/rng-tools/aarch64
>
> Friendly ping. Is there any more concern on this?

My concern is that will it be so for all aarch64 machines ?

>
>
> Thanks,
>
> Xiangyu
>
> > ---
> >   .../rng-tools/rng-tools/aarch64/default   | 11 +++
> >   1 file changed, 11 insertions(+)
> >   create mode 100644 
> > meta/recipes-support/rng-tools/rng-tools/aarch64/default
> >
> > diff --git a/meta/recipes-support/rng-tools/rng-tools/aarch64/default 
> > b/meta/recipes-support/rng-tools/rng-tools/aarch64/default
> > new file mode 100644
> > index 00..5a2fbcc9ef
> > --- /dev/null
> > +++ b/meta/recipes-support/rng-tools/rng-tools/aarch64/default
> > @@ -0,0 +1,11 @@
> > +# With the default jitter options Arm CPU-based devices typically 
> > experience
> > +# continuous high CPU utilisation for several minutes after rngd starts.
> > +# See https://gitlab.alpinelinux.org/alpine/aports/-/issues/13035 and
> > +# https://github.com/nhorman/rng-tools/issues/150
> > +# In order to address this the following configuration changes have been 
> > made:
> > +#
> > +#   - reduce the number of threads used to 1 in total, rather than 1 per 
> > core.
> > +#   - reduce the buffer size from 16535 to 4133 which reduces the time 
> > taken
> > +# to fill the buffer (and so reduces the duration of CPU load).
> > +#
> > +EXTRA_ARGS="-r /dev/hwrng -O jitter:buffer_size:4133 -O 
> > jitter:refill_thresh:4133 -O jitter:thread_count:1"
> >
> >
> >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172820): 
https://lists.openembedded.org/g/openembedded-core/message/172820
Mute This Topic: https://lists.openembedded.org/mt/94701000/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] Dunfell toolchain update analysis

[Khem Raj]

On Sun, Nov 6, 2022 at 4:20 PM Philip Balister  wrote:
>
> On 11/2/22 09:00, Steve Sakoman wrote:
> > On Wed, Nov 2, 2022 at 2:24 AM Randy MacLeod
> >  wrote:
> >>
> >> Thanks for the info I requested Sundeep.
> >>
> >>
> >> Steve or anyone using dunfell,
> >>
> >> Do you have any concerns with the updates shown below?
> >
> > The glibc and binutils updates seem fine.  The gcc update(s) concern
> > me a little bit, but we can test and see if any issues arise.
>
> The release notes for gcc might concern me if I was trying for super
> stable  But, we created some gcc-9.5 recipes and found they fixed a
> segfault in the fftw QA which offset any concern we had. I'd love to see
> gcc updated in Dunfel, but if it isn't I plan to create a layer that
> will overlay the newer gcc in Dunfell to resolve the fftw issue (with 32
> arm+neon)

9.5 is a bug fix release in gcc-9 series so it should qualify for
stable update for dunfell.

>
> Philip
>
> >
> > Steve
> >
> >> Hello Randy,
> >>
> >> I checked the Dunfell branch for gcc, glibc & binutils updates.
> >>
> >> gcc-9.3 is currently used in Dunfell and gcc-9.5 was released by gcc.
> >> glibc-2.31 is used by Dunfell and latest commits in this branch are listed 
> >> in attached file 'glibc.log'
> >> binutils-2.34 is used by Dunfell and latest commits in this branch are 
> >> listed in attached file 'binutils-gdb.log'
> >>
> >> Can I update all these 3 modules as mentioned above?
> >>
> >>
> >> Thanks,
> >> Sundeep K.
> >>
> >>
> >>
> >>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172818): 
https://lists.openembedded.org/g/openembedded-core/message/172818
Mute This Topic: https://lists.openembedded.org/mt/94732697/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 2/2] gcc-source: Drop gengtype manipulation

[Khem Raj]

On Thu, Nov 3, 2022 at 5:41 AM Richard Purdie
 wrote:
>
> Whilst we patch gengtype.cc, we don't patch gengtype-lex.cc which would
> be the file which would trigger regeneration of files.
>
> The real bug that was likely the cause for this fix is probably SDE issues
> with gcc shared workdir so this code can now be dropped.
>

good catch. LGTM

> Signed-off-by: Richard Purdie 
> ---
>  meta/recipes-devtools/gcc/gcc-source.inc | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-source.inc 
> b/meta/recipes-devtools/gcc/gcc-source.inc
> index 03837f43811..bf33a4b31ff 100644
> --- a/meta/recipes-devtools/gcc/gcc-source.inc
> +++ b/meta/recipes-devtools/gcc/gcc-source.inc
> @@ -25,8 +25,6 @@ python do_preconfigure () {
>  import subprocess
>  cmd = d.expand('cd ${S} && PATH=${PATH} gnu-configize')
>  subprocess.check_output(cmd, stderr=subprocess.STDOUT, shell=True)
> -# See 0044-gengtypes.patch, we need to regenerate this file
> -bb.utils.remove(d.expand("${S}/gcc/gengtype-lex.cc"))
>  cmd = d.expand("sed -i 's/BUILD_INFO=info/BUILD_INFO=/' 
> ${S}/gcc/configure")
>  subprocess.check_output(cmd, stderr=subprocess.STDOUT, shell=True)
>
> --
> 2.34.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172648): 
https://lists.openembedded.org/g/openembedded-core/message/172648
Mute This Topic: https://lists.openembedded.org/mt/94755300/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 v2] bluez5: Point hciattach bcm43xx firmware search path to /lib/firmware

[Khem Raj]

On 11/1/22 4:54 AM, Marek Vasut wrote:

Currently the hciattach bcm43xx firmware loader looks up the firmware
blob in /etc/firmware . Change this to /lib/firmware instead, so that
the path is consistent with Linux kernel which also looks up firmware
for the WiFi part in /lib/firmware .

Signed-off-by: Marek Vasut 
---
Cc: Alexander Kanavin 
Cc: Alexandre Belloni 
Cc: Richard Purdie 
---
V2: Replace hard-coded /lib with ${nonarch_base_libdir}
---
  meta/recipes-connectivity/bluez5/bluez5.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index f07e318897..a2aa7b86c4 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -68,6 +68,8 @@ EXTRA_OECONF = "\
--without-zsh-completion-dir \
  "
  
+CFLAGS:append = " -DFIRMWARE_DIR=\\"${nonarch_base_libdir}/firmware\\""


why do we use append and not += here ?


+
  # bluez5 builds a large number of useful utilities but does not
  # install them.  Specify which ones we want put into ${PN}-noinst-tools.
  NOINST_TOOLS_READLINE ??= ""







OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172387): 
https://lists.openembedded.org/g/openembedded-core/message/172387
Mute This Topic: https://lists.openembedded.org/mt/94707064/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] perf: Depend on native setuptools3

[Khem Raj]

On 11/1/22 10:11 AM, Fabio Estevam wrote:

Hi Armin,

On Tue, Oct 11, 2022 at 12:02 AM Khem Raj  wrote:


perf has need for python setuptools when scripting is enabled
from 6.0.0 onwards it seems to throw an explicit error

Signed-off-by: Khem Raj 
Cc: Bruce Ashfield 


This one landed in master:
https://github.com/openembedded/openembedded-core/commit/da3d00178809bbf7cc453401e0c5937796ebc2c1

Could it be backported to kirkstone too?

I am facing an error when building a 6.0 kernel and this commit in
master fixes it.

Thanks


+Steve



OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172371): 
https://lists.openembedded.org/g/openembedded-core/message/172371
Mute This Topic: https://lists.openembedded.org/mt/94251905/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] OE-core CVE metrics for master on Sun 30 Oct 2022 02:00:01 AM HST

[Khem Raj]

On Sun, Oct 30, 2022 at 5:03 AM Steve Sakoman  wrote:
>
> Branch: master
>
> New this week: 2 CVEs
> CVE-2022-3705 (CVSS3: 7.5 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3705 *
> CVE-2022-43680 (CVSS3: 7.5 HIGH): expat:expat-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-43680 *
>
> Removed this week: 17 CVEs
> CVE-2022-3165 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3165 *
> CVE-2022-3352 (CVSS3: 7.8 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3352 *
> CVE-2022-3358 (CVSS3: 7.5 HIGH): openssl:openssl-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3358 *
> CVE-2022-3550 (CVSS3: 9.8 CRITICAL): xserver-xorg 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3550 *
> CVE-2022-3551 (CVSS3: 7.5 HIGH): xserver-xorg 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3551 *
> CVE-2022-3553 (CVSS3: 7.5 HIGH): xserver-xorg 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3553 *
> CVE-2022-3554 (CVSS3: 7.5 HIGH): libx11:libx11-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3554 *
> CVE-2022-3555 (CVSS3: 7.5 HIGH): libx11:libx11-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3555 *
> CVE-2022-3570 (CVSS3: 9.8 CRITICAL): tiff 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3570 *
> CVE-2022-3597 (CVSS3: 6.5 MEDIUM): tiff 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3597 *
> CVE-2022-3598 (CVSS3: 6.5 MEDIUM): tiff 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3598 *
> CVE-2022-3599 (CVSS3: 6.5 MEDIUM): tiff 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3599 *
> CVE-2022-3626 (CVSS3: 6.5 MEDIUM): tiff 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3626 *
> CVE-2022-3627 (CVSS3: 6.5 MEDIUM): tiff 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3627 *
> CVE-2022-39253 (CVSS3: 5.5 MEDIUM): git 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-39253 *
> CVE-2022-39260 (CVSS3: 8.8 HIGH): git 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-39260 *
> CVE-2022-41556 (CVSS3: 7.5 HIGH): lighttpd 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-41556 *
>
> Full list:  Found 5 unpatched CVEs
> CVE-2022-2879 (CVSS3: 7.5 HIGH): go 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-2879 *
> CVE-2022-2880 (CVSS3: 7.5 HIGH): go 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-2880 *
> CVE-2022-3705 (CVSS3: 7.5 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3705 *
> CVE-2022-41715 (CVSS3: 7.5 HIGH): go 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-41715 *

Sent a patch for 1.19.2 upgrade which should take care of all go CVEs
reported here.

> CVE-2022-43680 (CVSS3: 7.5 HIGH): expat:expat-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-43680 *
>
> For further information see: 
> https://autobuilder.yocto.io/pub/non-release/patchmetrics/
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172329): 
https://lists.openembedded.org/g/openembedded-core/message/172329
Mute This Topic: https://lists.openembedded.org/mt/94662953/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] go: Upgrade to 1.19.2

[Khem Raj]

go1.19.1 (released 2022-09-06) includes security fixes to the net/http and 
net/url packages,
as well as bug fixes to the compiler, the go command, the pprof command, the 
linker, the
runtime, and the crypto/tls and crypto/x509 packages. See the Go 1.19.1 
milestone[1] on our
issue tracker for details.

go1.19.2 (released 2022-10-04) includes security fixes to the archive/tar,
net/http/httputil, and regexp packages, as well as bug fixes to the compiler, 
the linker,
the runtime, and the go/types package. See the Go 1.19.2 milestone[2] on our 
issue tracker
for details.

Forward port patches as needed
Drop stack-protector.patch, its already upstream

Includes fixed for CVE-2022-2879, CVE-2022-2880, and CVE-2022-41715

[1] 
https://github.com/golang/go/issues?q=milestone%3AGo1.19.1+label%3ACherryPickApproved
[2] 
https://github.com/golang/go/issues?q=milestone%3AGo1.19.2+label%3ACherryPickApproved

Signed-off-by: Khem Raj 
---
 .../go/{go-1.19.inc => go-1.19.2.inc} |  3 +-
 ...ive_1.19.bb => go-binary-native_1.19.2.bb} |  6 ++--
 ...an_1.19.bb => go-cross-canadian_1.19.2.bb} |  0
 .../{go-cross_1.19.bb => go-cross_1.19.2.bb}  |  0
 ...crosssdk_1.19.bb => go-crosssdk_1.19.2.bb} |  0
 ...{go-native_1.19.bb => go-native_1.19.2.bb} |  0
 ...o-runtime_1.19.bb => go-runtime_1.19.2.bb} |  0
 ...ent-based-hash-generation-less-pedan.patch | 22 ++---
 .../go/go/stack-protector.patch   | 32 ---
 .../go/{go_1.19.bb => go_1.19.2.bb}   |  0
 10 files changed, 13 insertions(+), 50 deletions(-)
 rename meta/recipes-devtools/go/{go-1.19.inc => go-1.19.2.inc} (85%)
 rename meta/recipes-devtools/go/{go-binary-native_1.19.bb => 
go-binary-native_1.19.2.bb} (77%)
 rename meta/recipes-devtools/go/{go-cross-canadian_1.19.bb => 
go-cross-canadian_1.19.2.bb} (100%)
 rename meta/recipes-devtools/go/{go-cross_1.19.bb => go-cross_1.19.2.bb} (100%)
 rename meta/recipes-devtools/go/{go-crosssdk_1.19.bb => go-crosssdk_1.19.2.bb} 
(100%)
 rename meta/recipes-devtools/go/{go-native_1.19.bb => go-native_1.19.2.bb} 
(100%)
 rename meta/recipes-devtools/go/{go-runtime_1.19.bb => go-runtime_1.19.2.bb} 
(100%)
 delete mode 100644 meta/recipes-devtools/go/go/stack-protector.patch
 rename meta/recipes-devtools/go/{go_1.19.bb => go_1.19.2.bb} (100%)

diff --git a/meta/recipes-devtools/go/go-1.19.inc 
b/meta/recipes-devtools/go/go-1.19.2.inc
similarity index 85%
rename from meta/recipes-devtools/go/go-1.19.inc
rename to meta/recipes-devtools/go/go-1.19.2.inc
index f733a807b4..206ee3ca45 100644
--- a/meta/recipes-devtools/go/go-1.19.inc
+++ b/meta/recipes-devtools/go/go-1.19.2.inc
@@ -14,6 +14,5 @@ SRC_URI += "\
 file://0001-exec.go-do-not-write-linker-flags-into-buildids.patch \
 file://0001-src-cmd-dist-buildgo.go-do-not-hardcode-host-compile.patch \
 file://filter-build-paths.patch \
-file://stack-protector.patch \
 "
-SRC_URI[main.sha256sum] = 
"9419cc70dc5a2523f29a77053cafff658ed21ef3561d9b6b020280ebceab28b9"
+SRC_URI[main.sha256sum] = 
"2ce930d70a931de660fdaf271d70192793b1b240272645bf0275779f6704df6b"
diff --git a/meta/recipes-devtools/go/go-binary-native_1.19.bb 
b/meta/recipes-devtools/go/go-binary-native_1.19.2.bb
similarity index 77%
rename from meta/recipes-devtools/go/go-binary-native_1.19.bb
rename to meta/recipes-devtools/go/go-binary-native_1.19.2.bb
index eda90f3753..ebf45954e6 100644
--- a/meta/recipes-devtools/go/go-binary-native_1.19.bb
+++ b/meta/recipes-devtools/go/go-binary-native_1.19.2.bb
@@ -8,9 +8,9 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707"
 PROVIDES = "go-native"
 
 SRC_URI = 
"https://dl.google.com/go/go${PV}.${BUILD_GOOS}-${BUILD_GOARCH}.tar.gz;name=go_${BUILD_GOTUPLE};
-SRC_URI[go_linux_amd64.sha256sum] = 
"464b6b66591f6cf055bc5df90a9750bf5fbc9d038722bb84a9d56a2bea974be6"
-SRC_URI[go_linux_arm64.sha256sum] = 
"efa97fac9574fc6ef6c9ff3e3758fb85f1439b046573bf434cccb5e012bd00c8"
-SRC_URI[go_linux_ppc64le.sha256sum] = 
"92bf5aa598a01b279d03847c32788a3a7e0a247a029dedb7c759811c2a4241fc"
+SRC_URI[go_linux_amd64.sha256sum] = 
"5e8c5a74fe6470dd7e055a461acda8bb4050ead8c2df70f227e3ff7d8eb7eeb6"
+SRC_URI[go_linux_arm64.sha256sum] = 
"b62a8d9654436c67c14a0c91e931d50440541f09eb991a987536cb982903126d"
+SRC_URI[go_linux_ppc64le.sha256sum] = 
"37e1d4342f7103aeb9babeabe8c71ef3dba23db28db525071119e94b2aa21d7d"
 
 UPSTREAM_CHECK_URI = "https://golang.org/dl/;
 UPSTREAM_CHECK_REGEX = "go(?P\d+(\.\d+)+)\.linux"
diff --git a/meta/recipes-devtools/go/go-cross-canadian_1.19.bb 
b/meta/recipes-devtools/go/go-cross-canadian_1.19.2.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-cross-canadian_1.19.bb
rename to meta/recipes-devtools/go/go-cross-canadian_1.19.2.bb
diff --git a/meta/recipes-devtools/go/go-cross_1.19.bb 
b/meta/recipes-devtools/go/go-cross_1.

Re: [OE-Core][kirkstone][master][PATCH] rng-tools: Add Arm aarch64 CPU specific configuration to address excessive CPU usage on startup

[Khem Raj]

On Mon, Oct 31, 2022 at 12:51 AM Xiangyu Chen
 wrote:
>
> With the default jitter options aarch64 CPU-based devices typically 
> experience continuous
> high CPU utilisation for several minutes after rngd starts.
>
> Accoring to the rng-tools issue #150[1] and comments[2],in order to address 
> this,
> the following configuration changes have been made, those configurations
> also can be found on Alpine Linux[3]:
>
> - reduce the number of threads used to 1 in total, rather than 1 per core.
> - reduce the buffer size from 16535 to 4133 which reduces the time taken
>   to fill the buffer (and so reduces the duration of CPU load).
>
> [1] https://github.com/nhorman/rng-tools/issues/150
> [2] https://github.com/nhorman/rng-tools/issues/150#issuecomment-953079212
> [3] https://git.alpinelinux.org/aports/tree/main/rng-tools/rngd.confd-arm
>
> Signed-off-by: Xiangyu Chen 
> ---
>  .../rng-tools/rng-tools/default.aarch64   | 11 +++
>  meta/recipes-support/rng-tools/rng-tools_6.15.bb  |  5 +
>  2 files changed, 16 insertions(+)
>  create mode 100644 meta/recipes-support/rng-tools/rng-tools/default.aarch64
>
> diff --git a/meta/recipes-support/rng-tools/rng-tools/default.aarch64 
> b/meta/recipes-support/rng-tools/rng-tools/default.aarch64
> new file mode 100644
> index 00..5a2fbcc9ef
> --- /dev/null
> +++ b/meta/recipes-support/rng-tools/rng-tools/default.aarch64
> @@ -0,0 +1,11 @@
> +# With the default jitter options Arm CPU-based devices typically experience
> +# continuous high CPU utilisation for several minutes after rngd starts.
> +# See https://gitlab.alpinelinux.org/alpine/aports/-/issues/13035 and
> +# https://github.com/nhorman/rng-tools/issues/150
> +# In order to address this the following configuration changes have been 
> made:
> +#
> +#   - reduce the number of threads used to 1 in total, rather than 1 per 
> core.
> +#   - reduce the buffer size from 16535 to 4133 which reduces the time taken
> +# to fill the buffer (and so reduces the duration of CPU load).
> +#
> +EXTRA_ARGS="-r /dev/hwrng -O jitter:buffer_size:4133 -O 
> jitter:refill_thresh:4133 -O jitter:thread_count:1"
> diff --git a/meta/recipes-support/rng-tools/rng-tools_6.15.bb 
> b/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> index 0696351903..e1f6b2ad77 100644
> --- a/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> +++ b/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> @@ -12,6 +12,7 @@ SRC_URI = 
> "git://github.com/nhorman/rng-tools.git;branch=master;protocol=https \
> file://init \
> file://default \
> file://rngd.service \
> +   file://default.aarch64 \
> "
>  SRCREV = "381f69828b782afda574f259c1b7549f48f9bb77"
>
> @@ -59,3 +60,7 @@ do_install:append() {
>  ${D}${systemd_system_unitdir}/rngd.service
>  fi
>  }
> +
> +do_install:append:aarch64() {
> +install -Dm 0644 ${WORKDIR}/default.aarch64 
> ${D}${sysconfdir}/default/rng-tools
> +}

Perhaps drop the aarch64 specific default file inside a folder called
aarch64 under meta/recipes-support/rng-tools/rng-tools
and we don't need any changes in recipe.

> --
> 2.34.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172323): 
https://lists.openembedded.org/g/openembedded-core/message/172323
Mute This Topic: https://lists.openembedded.org/mt/94680433/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] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

On Wed, Oct 26, 2022 at 12:58 AM Alexander Kanavin
 wrote:
>
> On Wed, 26 Oct 2022 at 02:46, Khem Raj  wrote:
> > Thanks, I think we can also unbolt the workaround in librsvg as well.
> >
> > diff --git a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> > b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> > index fc52ae61c5..daf60217d4 100644
> > --- a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> > +++ b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> > @@ -35,7 +35,6 @@ export RUST_TARGET = "${RUST_HOST_SYS}"
> >  RUSTFLAGS:append:mips = " --cfg crossbeam_no_atomic_64"
> >  RUSTFLAGS:append:mipsel = " --cfg crossbeam_no_atomic_64"
> >  RUSTFLAGS:append:powerpc = " --cfg crossbeam_no_atomic_64"
> > -RUSTFLAGS:append:riscv32 = " --cfg crossbeam_no_atomic_64"
>
> Not yet. librsvg carries its own copy of crossbeam which is not
> patched to use the provided standard lists.

right saw that

>
> So we should first merge some variant of crossbeam_atomic.patch
> upstream. My previous attempt went nowhere:
> https://github.com/crossbeam-rs/crossbeam/pull/751
>
> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172153): 
https://lists.openembedded.org/g/openembedded-core/message/172153
Mute This Topic: https://lists.openembedded.org/mt/94464934/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] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

On Tue, Oct 25, 2022 at 9:15 AM Alexander Kanavin
 wrote:
>
> Ok, I have looked into this properly now. So:
>
> - the fail started to occur in 1.64 because crossbeam-utils is now a
> dependency of rust core (hard fail) and not just rustfmt (soft fail)
> - the correct way to address it is indeed to map oe arch (riscv32) to
> rust arch (riscv32gc) via meta/lib/oe/rust.py, which works globally
> across all recipes where this may occur.
> - however doing that exposed confusion about how we map arches, as
> there is actually a *third* arch involved (the internal llvm one
> listed in custom target definition), which too needs to be correctly
> mapped from oe arch so I fixed that as well.
>
> None of the three arch sets match each other exactly, unfortunately.

Right.

>
> Patches are coming shortly.
>

Thanks, I think we can also unbolt the workaround in librsvg as well.

diff --git a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
index fc52ae61c5..daf60217d4 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
@@ -35,7 +35,6 @@ export RUST_TARGET = "${RUST_HOST_SYS}"
 RUSTFLAGS:append:mips = " --cfg crossbeam_no_atomic_64"
 RUSTFLAGS:append:mipsel = " --cfg crossbeam_no_atomic_64"
 RUSTFLAGS:append:powerpc = " --cfg crossbeam_no_atomic_64"
-RUSTFLAGS:append:riscv32 = " --cfg crossbeam_no_atomic_64"

 CARGO_DISABLE_BITBAKE_VENDORING = "1"
 do_configure[postfuncs] += "cargo_common_do_configure"

> Alex
>
> On Sat, 22 Oct 2022 at 21:56, Alexander Kanavin via
> lists.openembedded.org 
> wrote:
> >
> > Ok, I'd like to understand where the failure is exactly. I just ran
> > 'bitbake rust' with poky master (rust 1.63) for qemuriscv32 machine,
> > and it succeeded. How can I see the fail? Did this become broken with
> > a 1.64.0 upgrade in your branch? (which I believe hasn't yet been
> > through the autobuilder, and so might show similar fails for other
> > targets without atomic_64 support)
> >
> > Alex
> >
> > On Fri, 21 Oct 2022 at 00:30, Khem Raj  wrote:
> > >
> > > riscv32 builds fail since AtomicI64 is not available in sync::atomic for
> > > this architecture. Therefore it needs to be opted out and the way out is
> > > to pass it by RUSTFLAGS, however rust target recipe overrides RUSTFLAGS
> > > before exporting it so its better to piggy back on the variable its
> > > using which is RUST_DEBUG_REMAP
> > >
> > > Signed-off-by: Khem Raj 
> > > ---
> > >  meta/recipes-devtools/rust/rust_1.64.0.bb | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/meta/recipes-devtools/rust/rust_1.64.0.bb 
> > > b/meta/recipes-devtools/rust/rust_1.64.0.bb
> > > index 1f9dbd3cce..b05f188d9c 100644
> > > --- a/meta/recipes-devtools/rust/rust_1.64.0.bb
> > > +++ b/meta/recipes-devtools/rust/rust_1.64.0.bb
> > > @@ -9,6 +9,7 @@ FILES:${PN}-dev = ""
> > >
> > >  # Used by crossbeam_atomic.patch
> > >  export TARGET_VENDOR
> > > +RUST_DEBUG_REMAP:append:riscv32 = " --cfg crossbeam_no_atomic_64"
> > >
> > >  do_compile () {
> > >  rust_runx build --stage 2
> > > --
> > > 2.38.1
> > >
> > >
> > >
> > >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172144): 
https://lists.openembedded.org/g/openembedded-core/message/172144
Mute This Topic: https://lists.openembedded.org/mt/94464934/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 1/2] rust-target-config: match riscv target names with what rust expects

[Khem Raj]

On Tue, Oct 25, 2022 at 11:44 AM Alexander Kanavin
 wrote:
>
> Official rust risc-v targets are prefixed with riscv32gc- and riscv64gc-:
> https://doc.rust-lang.org/nightly/rustc/platform-support.html
>
> Particularly crossbeam-utils make important build time decisions
> for atomics based on those names, and so we need to match ours
> with official targets.
>
> On the other hand, the actual definitions for those targets do not
> use the 'gc' suffix in 'arch' and 'llvm-target' fields, and so we
> need to follow that too, to avoid cryptic mismatch errors from rust-llvm:
> https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/riscv32gc_unknown_linux_gnu.rs
>

This approach seems good to me. I wonder if rust_sys_to_llvm_target
would be problematic
for vardep calculations on native targets.

> Signed-off-by: Alexander Kanavin 
> ---
>  .../classes-recipe/rust-target-config.bbclass | 40 ---
>  meta/lib/oe/rust.py   |  2 +
>  2 files changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/meta/classes-recipe/rust-target-config.bbclass 
> b/meta/classes-recipe/rust-target-config.bbclass
> index 9e1d81bf5c..2710b4325d 100644
> --- a/meta/classes-recipe/rust-target-config.bbclass
> +++ b/meta/classes-recipe/rust-target-config.bbclass
> @@ -231,19 +231,19 @@ TARGET_POINTER_WIDTH[powerpc64le] = "64"
>  TARGET_C_INT_WIDTH[powerpc64le] = "64"
>  MAX_ATOMIC_WIDTH[powerpc64le] = "64"
>
> -## riscv32-unknown-linux-{gnu, musl}
> -DATA_LAYOUT[riscv32] = "e-m:e-p:32:32-i64:64-n32-S128"
> -TARGET_ENDIAN[riscv32] = "little"
> -TARGET_POINTER_WIDTH[riscv32] = "32"
> -TARGET_C_INT_WIDTH[riscv32] = "32"
> -MAX_ATOMIC_WIDTH[riscv32] = "32"
> -
> -## riscv64-unknown-linux-{gnu, musl}
> -DATA_LAYOUT[riscv64] = "e-m:e-p:64:64-i64:64-i128:128-n64-S128"
> -TARGET_ENDIAN[riscv64] = "little"
> -TARGET_POINTER_WIDTH[riscv64] = "64"
> -TARGET_C_INT_WIDTH[riscv64] = "64"
> -MAX_ATOMIC_WIDTH[riscv64] = "64"
> +## riscv32gc-unknown-linux-{gnu, musl}
> +DATA_LAYOUT[riscv32gc] = "e-m:e-p:32:32-i64:64-n32-S128"
> +TARGET_ENDIAN[riscv32gc] = "little"
> +TARGET_POINTER_WIDTH[riscv32gc] = "32"
> +TARGET_C_INT_WIDTH[riscv32gc] = "32"
> +MAX_ATOMIC_WIDTH[riscv32gc] = "32"
> +
> +## riscv64gc-unknown-linux-{gnu, musl}
> +DATA_LAYOUT[riscv64gc] = "e-m:e-p:64:64-i64:64-i128:128-n64-S128"
> +TARGET_ENDIAN[riscv64gc] = "little"
> +TARGET_POINTER_WIDTH[riscv64gc] = "64"
> +TARGET_C_INT_WIDTH[riscv64gc] = "64"
> +MAX_ATOMIC_WIDTH[riscv64gc] = "64"
>
>  # Convert a normal arch (HOST_ARCH, TARGET_ARCH, BUILD_ARCH, etc) to 
> something
>  # rust's internals won't choke on.
> @@ -258,9 +258,21 @@ def arch_to_rust_target_arch(arch):
>  return "arm"
>  elif arch == "powerpc64le":
>  return "powerpc64"
> +elif arch == "riscv32gc":
> +return "riscv32"
> +elif arch == "riscv64gc":
> +return "riscv64"
>  else:
>  return arch
>
> +# Convert a rust target string to a llvm-compatible triplet
> +def rust_sys_to_llvm_target(sys):
> +if sys.startswith('riscv32gc-'):
> +return sys.replace('riscv32gc-', 'riscv32-', 1)
> +if sys.startswith('riscv64gc-'):
> +return sys.replace('riscv64gc-', 'riscv64-', 1)
> +return sys
> +
>  # generates our target CPU value
>  def llvm_cpu(d):
>  cpu = d.getVar('PACKAGE_ARCH')
> @@ -334,7 +346,7 @@ def rust_gen_target(d, thing, wd, arch):
>
>  # build tspec
>  tspec = {}
> -tspec['llvm-target'] = rustsys
> +tspec['llvm-target'] = rust_sys_to_llvm_target(rustsys)
>  tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
>  if tspec['data-layout'] is None:
>  bb.fatal("No rust target defined for %s" % arch_abi)
> diff --git a/meta/lib/oe/rust.py b/meta/lib/oe/rust.py
> index 1dc9cf150d..185553eeeb 100644
> --- a/meta/lib/oe/rust.py
> +++ b/meta/lib/oe/rust.py
> @@ -8,4 +8,6 @@
>  def arch_to_rust_arch(arch):
>  if arch == "ppc64le":
>  return "powerpc64le"
> +if arch in ('riscv32', 'riscv64'):
> +return arch + 'gc'
>  return arch
> --
> 2.30.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172143): 
https://lists.openembedded.org/g/openembedded-core/message/172143
Mute This Topic: https://lists.openembedded.org/mt/94565465/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 v2] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

On Fri, Oct 21, 2022 at 7:58 PM Alexander Kanavin 
wrote:

>
>
> On Fri 21. Oct 2022 at 23.49, Khem Raj  wrote:
>
>> On Fri, Oct 21, 2022 at 2:01 PM Alexander Kanavin
>>  wrote:
>> >
>> > On Fri, 21 Oct 2022 at 22:05, Khem Raj  wrote:
>> > > Update the arch part of tuple to consider OE's names
>> > > for riscv32
>> >
>> > > +--- a/vendor/crossbeam-utils-0.8.8/no_atomic.rs
>> > >  b/vendor/crossbeam-utils-0.8.8/no_atomic.rs
>> > > +@@ -49,6 +49,8 @@ const NO_ATOMIC_64: &[] = &[
>> > > + "powerpc-wrs-vxworks-spe",
>> > > + "riscv32gc-unknown-linux-gnu",
>> > > + "riscv32gc-unknown-linux-musl",
>> > > ++"riscv32-unknown-linux-gnu",
>> > > ++"riscv32-unknown-linux-musl",
>> > > + "riscv32i-unknown-none-elf",
>> > > + "riscv32im-unknown-none-elf",
>> > > + "riscv32imac-unknown-none-elf",
>> >
>> > No. Updating this patch with every rust upgrade is already a pain in
>> > the ass due to rust checksumming, it needs to be upstreamed in some
>> > form rather sooner than later, and you just made it worse. Please
>> > let's do a proper arch re-mapping.
>>
>> we should apply the v1 of patch and move on.
>
>
> No again. Riscv32 is already listed so it’s on you to use existing mapping
> to use those entries, and not add new ones.
>

?
v1 is passing the needed options via cflags. No patching needed. If you
have better suggestions come up with a better patch


> Alex
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172058): 
https://lists.openembedded.org/g/openembedded-core/message/172058
Mute This Topic: https://lists.openembedded.org/mt/94484005/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 v2] mesa: Add native patch via a variable

[Khem Raj]

On Wed, Oct 19, 2022 at 8:29 AM Ross Burton  wrote:
>
> On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org 
>  wrote:
> >
> > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
> >  wrote:
> >>
> >> Can you show examples where this is needed? Custom variable does not seem 
> >> a good idea. I also worry that it’ll break automated updates (it’s bad 
> >> enough with mesa-gl, this might make it worse).
> >
> > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb
>
> That is, well, horrible.
>
> *If* we’re going to expose a mesa.inc that people outside of core can use to 
> package up their own random Mesa SHA then mesa.inc should just be the 
> packaging logic.

Right, and it will be an improvement for end users, since it helps in
deploying the mesa forks easy, We should be cognizant of the fact that
people are
doing their own distributions since that is what OE makes it easy and
is its USP.  Making it too rigid a policy also results in harder
forks.

>
> However, I don’t understand something about the patch.
>
> Why do we only need to apply it on native builds?  It’s a backport from 
> upstream, so should be the fix.  If it breaks when applied to target builds, 
> is there a bug upstream for that?
>

This is to provide a crutch to compile it with ubuntu 18.04 gcc.

> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172047): 
https://lists.openembedded.org/g/openembedded-core/message/172047
Mute This Topic: https://lists.openembedded.org/mt/94420106/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 v2] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

On Fri, Oct 21, 2022 at 2:01 PM Alexander Kanavin
 wrote:
>
> On Fri, 21 Oct 2022 at 22:05, Khem Raj  wrote:
> > Update the arch part of tuple to consider OE's names
> > for riscv32
>
> > +--- a/vendor/crossbeam-utils-0.8.8/no_atomic.rs
> >  b/vendor/crossbeam-utils-0.8.8/no_atomic.rs
> > +@@ -49,6 +49,8 @@ const NO_ATOMIC_64: &[] = &[
> > + "powerpc-wrs-vxworks-spe",
> > + "riscv32gc-unknown-linux-gnu",
> > + "riscv32gc-unknown-linux-musl",
> > ++"riscv32-unknown-linux-gnu",
> > ++"riscv32-unknown-linux-musl",
> > + "riscv32i-unknown-none-elf",
> > + "riscv32im-unknown-none-elf",
> > + "riscv32imac-unknown-none-elf",
>
> No. Updating this patch with every rust upgrade is already a pain in
> the ass due to rust checksumming, it needs to be upstreamed in some
> form rather sooner than later, and you just made it worse. Please
> let's do a proper arch re-mapping.

we should apply the v1 of patch and move on.

>
> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172046): 
https://lists.openembedded.org/g/openembedded-core/message/172046
Mute This Topic: https://lists.openembedded.org/mt/94484005/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 v3] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

Update the arch part of tuple to consider OE's names
for riscv32

Signed-off-by: Khem Raj 
---
- Add riscv32-* to known arches for crossbeam-utils
- Keep the patch for both crossbeam versions

 .../rust/rust/crossbeam_atomic.patch  | 26 ---
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch 
b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
index 2f3f985243..067918c048 100644
--- a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
+++ b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
@@ -48,19 +48,14 @@ Index: 
rustc-1.64.0-src/vendor/crossbeam-utils/.cargo-checksum.json
 \ No newline at end of file
 
+{"files":{"CHANGELOG.md":"c2cdac68fbf3795e9c3cb0bbeace5f87736d0745fefbd3db9c07f568dc70d1d1","Cargo.toml":"fc5b0f0f821aa944d4341dc97e7c3b4d4bf658483ba359b5bf2e53d8ad945ac9","LICENSE-APACHE":"a60eea817514531668d7e00765731449fe14d059d3249e0bc93b36de45f759f2","LICENSE-MIT":"5734ed989dfca1f625b40281ee9f4530f91b2411ec01cb748223e7eb87e201ab","README.md":"dfa9fbed47c344c134a63c84b7c0e4651baeac1554b7b3266d0e38643743fc33","benches/atomic_cell.rs":"c927eb3cd1e5ecc4b91adbc3bde98af15ffab4086190792ba64d5cde0e24df3d","build.rs":"d983d511c89607ce89473779d1ee195e3eb509cc4d3043b9efe6aa2f94c98158","no_atomic.rs":"916ed15218bb7b75a4e0d432430e7134efd27ca43ca8a8766e0c90e89febb602","src/atomic/atomic_cell.rs":"f1b407b62b981de47968236eabb932384722c4dd7b7f08f52c59943aefd0b113","src/atomic/consume.rs":"7a7736fcd64f6473dfea7653559ffc5e1a2a234df43835f8aa8734862145ac15","src/atomic/mod.rs":"94193895fa03cece415e8d7be700b73a9a8a7015774ca821253438607f9b0736","src/atomic/seq_lock.rs":"27182e6b87a9db73c5f6831759f8625f9fcdec3c2828204c444aef04f427735a","src/atomic/seq_lock_wide.rs":"9888dd03116bb89ca36d4ab8d5a0b5032107a2983a7eb8024454263b09080088","src/backoff.rs":"7cc7754e15f69b52e92a70d4f49d1bc274693455a0933a2d7eb0605806566af3","src/cache_padded.rs":"6a512698115ad0d5a5b163dbd7a83247e1f1c146c4a30f3fc74b952e3b767b59","src/lib.rs":"6f1bcf157abe06ad8458a53e865bf8efab9fad4a9424790147cee8fefb3795d8","src/sync/mod.rs":"59986f559a8f170a4b3247ab2eea2460b09809d87c8110ed88e4e7103d3519dc","src/sync/parker.rs":"3f997f5b41fec286ccedcf3d36f801d741387badb574820b8e3456117ecd9154","src/sync/sharded_lock.rs":"78433f55ee3defeea348d65abc78e03d63d6a304e09c568b27b403e9ad205771","src/sync/wait_group.rs":"32e946a7581c55f8aa9904527b92b177c538fa0cf7cbcfa1d1f25990582cb6ea","src/thread.rs":"21cf9b3e965529e5c0a6ff8fc1ec846bfe0006c41deb238a149be8d07384e955","tests/atomic_cell.rs":"bf8bc869c922a1cbf929c3b741bae0cae98f2157f572b5a4eb2873d20a407c22","tests/cache_padded.rs":"1bfaff8354c8184e1ee1f902881ca9400b60effb273b0d3f752801a483d2b66d","tests/parker.rs":"6def4721287d9d70b1cfd63ebb34e1c83fbb3376edbad2bc8aac6ef69dd99d20","tests/sharded_lock.rs":"314adeb8a651a28935f7a49c9a261b8fa1fd82bf6a16c865a5aced6216d7e40b","tests/thread.rs":"9a7d7d3028c552fd834c68598b04a1cc252a816bc20ab62cec060d6cd09cab10","tests/wait_group.rs":"ad8f0cdfed31f9594a2e0737234d418f8b924d784a4db8d7e469deab8c95f5f8"},"package":"7d82ee10ce34d7bc12c2122495e7593a9c41347ecdd64185af4ecf72cb1a7f83"}
 \ No newline at end of file
-Index: rustc-1.64.0-src/vendor/crossbeam-utils-0.8.8/.cargo-checksum.json
-===
 rustc-1.64.0-src.orig/vendor/crossbeam-utils-0.8.8/.cargo-checksum.json
-+++ rustc-1.64.0-src/vendor/crossbeam-utils-0.8.8/.cargo-checksum.json
+--- a/vendor/crossbeam-utils-0.8.8/.cargo-checksum.json
 b/vendor/crossbeam-utils-0.8.8/.cargo-checksum.json
 @@ -1 +1 @@
 
-{"files":{"CHANGELOG.md":"665a9f2c5fd37c98bef7c1b6eda753b58bb925d87e5b42d7298df973d7590631","Cargo.toml":"fe22292acd6a868e65baf225f90d5678678971642814d2d8e92a03954b8bdb40","LICENSE-APACHE":"a60eea817514531668d7e00765731449fe14d059d3249e0bc93b36de45f759f2","LICENSE-MIT":"5734ed989dfca1f625b40281ee9f4530f91b2411ec01cb748223e7eb87e201ab","README.md":"dfa9fbed47c344c134a63c84b7c0e4651baeac1554b7b3266d0e38643743fc33","benches/atomic_cell.rs":"c927eb3cd1e5ecc4b91adbc3bde98af15ffab4086190792ba64d5cde0e24df3d","build.rs":"7e74dc72343ff57e83d0a84a9fbdd9ff164589416590b4c3d2fba94bc96c","no_atomic.rs":"71b5f78fd701ce604aa766dd3d825fa5bed774282aae4d6c31

Re: [OE-core] [PATCH] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

On Fri, Oct 21, 2022 at 10:28 AM Alexander Kanavin
 wrote:
>
> On Fri, 21 Oct 2022 at 19:16, Khem Raj  wrote:
>
> > anyway, the builds failed at exactly the same point so as I sensed it
> > does not work.
>
> You need to find out why though. Upstream maintains a list, and we
> need to use it, and not duplicate it piecemeal.

It needs to be mapped or added. I have sent a patch to add OE's
understanding of target arch.

>
> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172043): 
https://lists.openembedded.org/g/openembedded-core/message/172043
Mute This Topic: https://lists.openembedded.org/mt/94464934/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 v2] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

Update the patch to apply to only 0.8.8 version
Update the arch part of tuple to consider OE's names
for riscv32

Signed-off-by: Khem Raj 
---
- Add riscv32-* to known arches for crossbeam-utils

 .../rust/rust/crossbeam_atomic.patch  | 57 ++-
 1 file changed, 16 insertions(+), 41 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch 
b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
index 2f3f985243..69a1cfeb2a 100644
--- a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
+++ b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
@@ -17,50 +17,14 @@ to create a patch that upstream might accept.
 Upstream-Status: Inappropriate [OE Specific tweak  but could be rewritten]
 Signed-off-by: Richard Purdie 
 
-Index: rustc-1.64.0-src/vendor/crossbeam-utils/build.rs
-===
 rustc-1.64.0-src.orig/vendor/crossbeam-utils/build.rs
-+++ rustc-1.64.0-src/vendor/crossbeam-utils/build.rs
-@@ -29,7 +29,7 @@ use std::env;
- include!("no_atomic.rs");
- 
- fn main() {
--let target = match env::var("TARGET") {
-+let mut target = match env::var("TARGET") {
- Ok(target) => target,
- Err(e) => {
- println!(
-@@ -40,6 +40,8 @@ fn main() {
- return;
- }
- };
-+let vendor = env::var("TARGET_VENDOR").unwrap();
-+target = target.replace(, "-unknown");
- 
- // Note that this is `no_*`, not `has_*`. This allows treating
- // `cfg(target_has_atomic = "ptr")` as true when the build script doesn't
-Index: rustc-1.64.0-src/vendor/crossbeam-utils/.cargo-checksum.json
-===
 rustc-1.64.0-src.orig/vendor/crossbeam-utils/.cargo-checksum.json
-+++ rustc-1.64.0-src/vendor/crossbeam-utils/.cargo-checksum.json
-@@ -1 +1 @@
--{"files":{"CHANGELOG.md":"c2cdac68fbf3795e9c3cb0bbeace5f87736d0745fefbd3db9c07f568dc70d1d1","Cargo.toml":"fc5b0f0f821aa944d4341dc97e7c3b4d4bf658483ba359b5bf2e53d8ad945ac9","LICENSE-APACHE":"a60eea817514531668d7e00765731449fe14d059d3249e0bc93b36de45f759f2","LICENSE-MIT":"5734ed989dfca1f625b40281ee9f4530f91b2411ec01cb748223e7eb87e201ab","README.md":"dfa9fbed47c344c134a63c84b7c0e4651baeac1554b7b3266d0e38643743fc33","benches/atomic_cell.rs":"c927eb3cd1e5ecc4b91adbc3bde98af15ffab4086190792ba64d5cde0e24df3d","build.rs":"7e74dc72343ff57e83d0a84a9fbdd9ff164589416590b4c3d2fba94bc96c","no_atomic.rs":"916ed15218bb7b75a4e0d432430e7134efd27ca43ca8a8766e0c90e89febb602","src/atomic/atomic_cell.rs":"f1b407b62b981de47968236eabb932384722c4dd7b7f08f52c59943aefd0b113","src/atomic/consume.rs":"7a7736fcd64f6473dfea7653559ffc5e1a2a234df43835f8aa8734862145ac15","src/atomic/mod.rs":"94193895fa03cece415e8d7be700b73a9a8a7015774ca821253438607f9b0736","src/atomic/seq_lock.rs":"27182e6b87a9db73c5f6831759f8625f9fcdec3c2828204c444aef04f427735a","src/atomic/seq_lock_wide.rs":"9888dd03116bb89ca36d4ab8d5a0b5032107a2983a7eb8024454263b09080088","src/backoff.rs":"7cc7754e15f69b52e92a70d4f49d1bc274693455a0933a2d7eb0605806566af3","src/cache_padded.rs":"6a512698115ad0d5a5b163dbd7a83247e1f1c146c4a30f3fc74b952e3b767b59","src/lib.rs":"6f1bcf157abe06ad8458a53e865bf8efab9fad4a9424790147cee8fefb3795d8","src/sync/mod.rs":"59986f559a8f170a4b3247ab2eea2460b09809d87c8110ed88e4e7103d3519dc","src/sync/parker.rs":"3f997f5b41fec286ccedcf3d36f801d741387badb574820b8e3456117ecd9154","src/sync/sharded_lock.rs":"78433f55ee3defeea348d65abc78e03d63d6a304e09c568b27b403e9ad205771","src/sync/wait_group.rs":"32e946a7581c55f8aa9904527b92b177c538fa0cf7cbcfa1d1f25990582cb6ea","src/thread.rs":"21cf9b3e965529e5c0a6ff8fc1ec846bfe0006c41deb238a149be8d07384e955","tests/atomic_cell.rs":"bf8bc869c922a1cbf929c3b741bae0cae98f2157f572b5a4eb2873d20a407c22","tests/cache_padded.rs":"1bfaff8354c8184e1ee1f902881ca9400b60effb273b0d3f752801a483d2b66d","tests/parker.rs":"6def4721287d9d70b1cfd63ebb34e1c83fbb3376edbad2bc8aac6ef69dd99d20","tests/sharded_lock.rs":"314adeb8a651a28935f7a49c9a261b8fa1fd82bf6a16c865a5aced6216d7e40b","tests/thread.rs":"9a7d7d3028c552fd834c68598b04a1cc252a816bc20ab62cec060d6cd09cab10","tests/wait_group.rs":"ad8f0cdfed31f9594a2e0737234d418f8b924d784a4db8d7e469deab8c95f5f8"},"package":"7d82ee10ce34d7bc12c2122495e7593a9c41347ecdd64185af4ecf72cb1a7f83&q

Re: [OE-core] [PATCH] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

On Fri, Oct 21, 2022 at 10:12 AM Alexander Kanavin
 wrote:
>
> On Fri, 21 Oct 2022 at 19:00, Khem Raj  wrote:
> > > On Fri, 21 Oct 2022 at 18:07, Khem Raj  wrote:
> > > > Looking briefly over the code, my educated guess is that target names
> > > > are still not matching
> > > > rusts tuple uses riscv32gc but we use riscv32
> > >
> > > I believe we have a remapping in meta/lib/oe/rust.py, can you check if
> > > that works?
> >
> > This is mapping host uname, it wont work.
>
> No, it's mapping the targets too. E.g. in rust-common.bbclass:
>
> # Responsible for taking Yocto triples and converting it to Rust triples
> def rust_base_triple(d, thing):
> '''
> Mangle bitbake's *_SYS into something that rust might support (see
> rust/mk/cfg/* for a list)
>
> Note that os is assumed to be some linux form
> '''
>
> # The llvm-target for armv7 is armv7-unknown-linux-gnueabihf
> if d.getVar('{}_ARCH'.format(thing)) == d.getVar('TARGET_ARCH')
> and target_is_armv7(d):
> arch = "armv7"
> else:
> arch = oe.rust.arch_to_rust_arch(d.getVar('{}_ARCH'.format(thing)))
>

anyway, the builds failed at exactly the same point so as I sensed it
does not work.

> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172038): 
https://lists.openembedded.org/g/openembedded-core/message/172038
Mute This Topic: https://lists.openembedded.org/mt/94464934/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] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

On Fri, Oct 21, 2022 at 9:19 AM Alexander Kanavin
 wrote:
>
> On Fri, 21 Oct 2022 at 18:07, Khem Raj  wrote:
> > Looking briefly over the code, my educated guess is that target names
> > are still not matching
> > rusts tuple uses riscv32gc but we use riscv32
>
> I believe we have a remapping in meta/lib/oe/rust.py, can you check if
> that works?

This is mapping host uname, it wont work.

>
> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172036): 
https://lists.openembedded.org/g/openembedded-core/message/172036
Mute This Topic: https://lists.openembedded.org/mt/94464934/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] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

On Fri, Oct 21, 2022 at 8:41 AM Alexander Kanavin
 wrote:
>
> On Fri, 21 Oct 2022 at 16:05, Khem Raj  wrote:
> > This patch is doing something else where its mapping and broadening
> > the architecture to match crossbeam's understanding of it.
> > Here issue is new where it does not yet realize that some
> > architectures do not have 64bit atomics implemented.
>
> Here's crossbeam's own list:
>
> https://github.com/crossbeam-rs/crossbeam/blob/master/no_atomic.rs
>
> You can see that riscv32 is in NO_ATOMIC_64, and
> crossbeam_atomic.patch ensures we use the list, so why do we need this
> change?

Looking briefly over the code, my educated guess is that target names
are still not matching
rusts tuple uses riscv32gc but we use riscv32

>
> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172030): 
https://lists.openembedded.org/g/openembedded-core/message/172030
Mute This Topic: https://lists.openembedded.org/mt/94464934/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] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

On Thu, Oct 20, 2022 at 11:04 PM Alexander Kanavin
 wrote:
>
> We carry this patch, so that manual per-target fixups like this are
> not needed, and crossbeam's internal lists are used properly:
>
> https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch?h=master-next=f4fe7cdaa7fc5785c55bd507c897f4d25d43cffa
>
> Is it not working somehow? Does the list itself need to be fixed?
>

This patch is doing something else where its mapping and broadening
the architecture to match crossbeam's understanding of it.
Here issue is new where it does not yet realize that some
architectures do not have 64bit atomics implemented.

> Alex
>
> On Fri, 21 Oct 2022 at 00:30, Khem Raj  wrote:
> >
> > riscv32 builds fail since AtomicI64 is not available in sync::atomic for
> > this architecture. Therefore it needs to be opted out and the way out is
> > to pass it by RUSTFLAGS, however rust target recipe overrides RUSTFLAGS
> > before exporting it so its better to piggy back on the variable its
> > using which is RUST_DEBUG_REMAP
> >
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/recipes-devtools/rust/rust_1.64.0.bb | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/recipes-devtools/rust/rust_1.64.0.bb 
> > b/meta/recipes-devtools/rust/rust_1.64.0.bb
> > index 1f9dbd3cce..b05f188d9c 100644
> > --- a/meta/recipes-devtools/rust/rust_1.64.0.bb
> > +++ b/meta/recipes-devtools/rust/rust_1.64.0.bb
> > @@ -9,6 +9,7 @@ FILES:${PN}-dev = ""
> >
> >  # Used by crossbeam_atomic.patch
> >  export TARGET_VENDOR
> > +RUST_DEBUG_REMAP:append:riscv32 = " --cfg crossbeam_no_atomic_64"
> >
> >  do_compile () {
> >  rust_runx build --stage 2
> > --
> > 2.38.1
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172020): 
https://lists.openembedded.org/g/openembedded-core/message/172020
Mute This Topic: https://lists.openembedded.org/mt/94464934/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] rust: Disable 64bit atomics on crossbeam on riscv32

[Khem Raj]

riscv32 builds fail since AtomicI64 is not available in sync::atomic for
this architecture. Therefore it needs to be opted out and the way out is
to pass it by RUSTFLAGS, however rust target recipe overrides RUSTFLAGS
before exporting it so its better to piggy back on the variable its
using which is RUST_DEBUG_REMAP

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/rust/rust_1.64.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/rust/rust_1.64.0.bb 
b/meta/recipes-devtools/rust/rust_1.64.0.bb
index 1f9dbd3cce..b05f188d9c 100644
--- a/meta/recipes-devtools/rust/rust_1.64.0.bb
+++ b/meta/recipes-devtools/rust/rust_1.64.0.bb
@@ -9,6 +9,7 @@ FILES:${PN}-dev = ""
 
 # Used by crossbeam_atomic.patch
 export TARGET_VENDOR
+RUST_DEBUG_REMAP:append:riscv32 = " --cfg crossbeam_no_atomic_64"
 
 do_compile () {
 rust_runx build --stage 2
-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172006): 
https://lists.openembedded.org/g/openembedded-core/message/172006
Mute This Topic: https://lists.openembedded.org/mt/94464934/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] run-postinsts: Set dependency for ldconfig to avoid boot issues

[Khem Raj]

On Thu, Oct 20, 2022 at 8:37 AM Alexander Kanavin
 wrote:
>
> On Thu, 20 Oct 2022 at 17:27, Khem Raj  wrote:
> > Good question. After= will wait for dependency but not explicitly
> > activate it whereas Requires= will
> > activate it as well if it's not activated yet. I think it's best to
> > try this unit on a system without ldconfig.service
> > for finding the exact behaviour.
>
> 'man systemd.unit' seems to say that the wait will only happen if the
> dependency is being started for some reason, including reasons
> unrelated to this unit. It stops just short of saying what happens if
> the dependency is not going to start at all (which would be 'nothing
> happens, this unit simply starts'). Not a well written description,
> there.

right. thats why I think its good to try it out

>
> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172003): 
https://lists.openembedded.org/g/openembedded-core/message/172003
Mute This Topic: https://lists.openembedded.org/mt/94453597/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] run-postinsts: Set dependency for ldconfig to avoid boot issues

[Khem Raj]

On Thu, Oct 20, 2022 at 8:18 AM Alexander Kanavin
 wrote:
>
> On Thu, 20 Oct 2022 at 17:08, Khem Raj  wrote:
> > > -After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount
> > > +After=systemd-remount-fs.service systemd-tmpfiles-setup.service 
> > > tmp.mount ldconfig.service
> >
> > ldconfig is not always enabled, it's controlled via a DISTRO_FEATURE
> > so this will fail for such
> > systems. Maybe adding it conditionally via a systemd unit fragment
> > drop-in file would be a better way to go.
>
> But will it fail? I thought Requires= is the hard dependency, and
> After= sets only the ordering, but not dependencies.
>

Good question. After= will wait for dependency but not explicitly
activate it whereas Requires= will
activate it as well if it's not activated yet. I think it's best to
try this unit on a system without ldconfig.service
for finding the exact behaviour.

> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172000): 
https://lists.openembedded.org/g/openembedded-core/message/172000
Mute This Topic: https://lists.openembedded.org/mt/94453597/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] run-postinsts: Set dependency for ldconfig to avoid boot issues

[Khem Raj]

On Thu, Oct 20, 2022 at 6:56 AM abuzarra via lists.openembedded.org
 wrote:
>
> If a package with a postsints script requires ldconfig, the package class adds
> a ldconfig postinst fragment to initialize it before. Systemd has its own
> ldconfig.service to initialize it and sometimes if both services are running
> at the same time in the first boot, the first one will work, but the second
> one will fail with the following error:
>
> ldconfig[141]: /sbin/ldconfig: Renaming of /etc/ld.so.cache~ to 
> /etc/ld.so.cache failed: No such file or directory
>
> This commit adds a ordering dependency between them to make sure that only one
> service is running at the same time.
>
> Signed-off-by: Arturo Buzarra 
> ---
>  .../run-postinsts/run-postinsts/run-postinsts.service   | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git 
> a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service 
> b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
> index 7f72f3388a..b6b81d5c1a 100644
> --- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
> +++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts.service
> @@ -1,9 +1,9 @@
>  [Unit]
>  Description=Run pending postinsts
>  DefaultDependencies=no
> -After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount
> +After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount 
> ldconfig.service

ldconfig is not always enabled, it's controlled via a DISTRO_FEATURE
so this will fail for such
systems. Maybe adding it conditionally via a systemd unit fragment
drop-in file would be a better way to go.

>  Before=sysinit.target
>
>  [Service]
>  Type=oneshot
>  ExecStart=#SBINDIR#/run-postinsts
> --
> 2.38.0
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171998): 
https://lists.openembedded.org/g/openembedded-core/message/171998
Mute This Topic: https://lists.openembedded.org/mt/94453597/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 v2] mesa: Add native patch via a variable

[Khem Raj]

On Tue, Oct 18, 2022 at 11:54 PM Alexander Kanavin
 wrote:
>
> On Wed, 19 Oct 2022 at 08:34, Khem Raj  wrote:
> >
> > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
> >  wrote:
> > >
> > > Can you show examples where this is needed? Custom variable does not seem 
> > > a good idea. I also worry that it’ll break automated updates (it’s bad 
> > > enough with mesa-gl, this might make it worse).
> >
> > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb
>
> "require recipes-graphics/mesa/mesa.inc"
>
> Using recipe includes across layers like this is not a good idea. It
> imposes requirements on core to continue providing the .inc, and not
> doing anything with mesa that can 'break' users of that include.
>

the reason for .inc to exist does include this usecase. oe-core
metadata is extensible by these constructs, it's similar
to bbclass perhaps a bit smaller in scope. Getting rid of .inc will
state that we do not allow other
layers to use it. These are APIs of sorts that oe-core exports and
people build on them, its fine if
they should be changed but there should some well understood path
otherwise they just make hard things harder.
The load of upgrading from one release to other is already high and it
keeps going up.

> Please make it self-contained.
>
> Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171969): 
https://lists.openembedded.org/g/openembedded-core/message/171969
Mute This Topic: https://lists.openembedded.org/mt/94420106/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 3/3] gnutls: Unified pakcage names to lower-case

[Khem Raj]

On Wed, Oct 19, 2022 at 4:08 AM Keiya Nobuta  wrote:
>
> create-spdx can't detect the license properly if the case doesn't
> match, so fix it.

I wonder if this could be some sort of QA warning that can flags such
issues, I do see this
might be a common error to make.

>
> Signed-off-by: Keiya Nobuta 
> ---
>  meta/recipes-support/gnutls/gnutls_3.7.7.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/gnutls/gnutls_3.7.7.bb 
> b/meta/recipes-support/gnutls/gnutls_3.7.7.bb
> index 01fd4dba3d..c7d782e4eb 100644
> --- a/meta/recipes-support/gnutls/gnutls_3.7.7.bb
> +++ b/meta/recipes-support/gnutls/gnutls_3.7.7.bb
> @@ -8,7 +8,7 @@ LICENSE = "GPL-3.0-or-later & LGPL-2.1-or-later"
>  LICENSE:${PN} = "LGPL-2.1-or-later"
>  LICENSE:${PN}-xx = "LGPL-2.1-or-later"
>  LICENSE:${PN}-bin = "GPL-3.0-or-later"
> -LICENSE:${PN}-OpenSSL = "GPL-3.0-or-later"
> +LICENSE:${PN}-openssl = "GPL-3.0-or-later"
>
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=71391c8e0c1cfe68077e7fce3b586283 \
>  file://doc/COPYING;md5=c678957b0c8e964aa6c70fd77641a71e \
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171968): 
https://lists.openembedded.org/g/openembedded-core/message/171968
Mute This Topic: https://lists.openembedded.org/mt/94428130/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 v2] mesa: Add native patch via a variable

[Khem Raj]

On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
 wrote:
>
> Can you show examples where this is needed? Custom variable does not seem a 
> good idea. I also worry that it’ll break automated updates (it’s bad enough 
> with mesa-gl, this might make it worse).

https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb

>
> Alex
>
> On Wed 19. Oct 2022 at 1.08, Khem Raj  wrote:
>>
>> This helps override the SRC_URI in entirety if needed by
>> and overriding recipe
>>
>> Signed-off-by: Khem Raj 
>> Cc: Kai Kang 
>> ---
>> v2: Weakly define NATIVE_PATCHES
>>
>>  meta/recipes-graphics/mesa/mesa.inc | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-graphics/mesa/mesa.inc 
>> b/meta/recipes-graphics/mesa/mesa.inc
>> index c94e439363..04d78a6aa5 100644
>> --- a/meta/recipes-graphics/mesa/mesa.inc
>> +++ b/meta/recipes-graphics/mesa/mesa.inc
>> @@ -19,10 +19,11 @@ SRC_URI = 
>> "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
>> file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
>> file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch 
>> \
>> file://0001-util-format-Check-for-NEON-before-using-it.patch \
>> +   ${NATIVE_PATCHES} \
>> "
>> -
>> +NATIVE_PATCHES ?= ""
>>  # required by mesa-native on Ubuntu 18.04 with gcc 7.5 when DEBUG_BUILD 
>> enabled
>> -SRC_URI:append:class-native = " 
>> file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch"
>> +NATIVE_PATCHES:class-native = 
>> "file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch"
>>
>>  SRC_URI[sha256sum] = 
>> "b1f9c8fd08f2cae3adf83355bef4d2398e8025f44947332880f2d0066bdafa8c"
>>
>> --
>> 2.38.0
>>
>>
>> 
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171958): 
https://lists.openembedded.org/g/openembedded-core/message/171958
Mute This Topic: https://lists.openembedded.org/mt/94420106/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 v2] mesa: Add native patch via a variable

[Khem Raj]

This helps override the SRC_URI in entirety if needed by
and overriding recipe

Signed-off-by: Khem Raj 
Cc: Kai Kang 
---
v2: Weakly define NATIVE_PATCHES

 meta/recipes-graphics/mesa/mesa.inc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index c94e439363..04d78a6aa5 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -19,10 +19,11 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \
file://0001-util-format-Check-for-NEON-before-using-it.patch \
+   ${NATIVE_PATCHES} \
"
-
+NATIVE_PATCHES ?= ""
 # required by mesa-native on Ubuntu 18.04 with gcc 7.5 when DEBUG_BUILD enabled
-SRC_URI:append:class-native = " 
file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch"
+NATIVE_PATCHES:class-native = 
"file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch"
 
 SRC_URI[sha256sum] = 
"b1f9c8fd08f2cae3adf83355bef4d2398e8025f44947332880f2d0066bdafa8c"
 
-- 
2.38.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171948): 
https://lists.openembedded.org/g/openembedded-core/message/171948
Mute This Topic: https://lists.openembedded.org/mt/94420106/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] mesa: Add native patch via a variable

[Khem Raj]

This helps override the SRC_URI in entirety if needed by
and overriding recipe

Signed-off-by: Khem Raj 
Cc: Kai Kang 
---
 meta/recipes-graphics/mesa/mesa.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index c94e439363..910e8929f8 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -19,10 +19,11 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \
file://0001-util-format-Check-for-NEON-before-using-it.patch \
+   ${NATIVE_PATCHES} \
"
 
 # required by mesa-native on Ubuntu 18.04 with gcc 7.5 when DEBUG_BUILD enabled
-SRC_URI:append:class-native = " 
file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch"
+NATIVE_PATCHES:class-native = 
"file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch"
 
 SRC_URI[sha256sum] = 
"b1f9c8fd08f2cae3adf83355bef4d2398e8025f44947332880f2d0066bdafa8c"
 
-- 
2.38.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171947): 
https://lists.openembedded.org/g/openembedded-core/message/171947
Mute This Topic: https://lists.openembedded.org/mt/94420021/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 v3] mesa: only apply patch to fix ALWAYS_INLINE for native

[Khem Raj]

On Wed, Oct 12, 2022 at 12:10 AM kai  wrote:
>
> On 9/30/22 16:34, kai wrote:
> > From: Kai Kang 
> >
> > 0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch is not
> > needed by target mesa any more. But it still fails to compile
> > mesa-native without this patch when DEBUG_BUILD is enabled on Ubuntu
> > 18.04 with gcc 7.5.0:
> >
> > | ../mesa-22.1.6/src/compiler/nir/nir_inline_helpers.h: In function 
> > ‘nir_opt_move_block’:
> > | ../mesa-22.1.6/src/compiler/nir/nir_opt_move.c:55:1: error: inlining 
> > failed in call to
> >  always_inline ‘src_is_ssa’: indirect function call with a yet 
> > undetermined callee
> > |  src_is_ssa(nir_src *src, void *state)
> > |  ^~
> >
> > So only apply it for mesa-native.
> >
> > Signed-off-by: Kai Kang 
> > ---
> > v3:
> > * rebase
>
> Ping.

This patch will break mesa recipes from other layers which override
mesa from core. They
won't be able to find this patch since now it will be inserted
previously where overriding SRC_URI
was enough, not anymore

>
> Kai
>
> >
> >   meta/recipes-graphics/mesa/mesa.inc | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-graphics/mesa/mesa.inc 
> > b/meta/recipes-graphics/mesa/mesa.inc
> > index 8a74e0a80a..c94e439363 100644
> > --- a/meta/recipes-graphics/mesa/mesa.inc
> > +++ b/meta/recipes-graphics/mesa/mesa.inc
> > @@ -19,9 +19,11 @@ SRC_URI = 
> > "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
> >  file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch 
> > \
> >  
> > file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \
> >  file://0001-util-format-Check-for-NEON-before-using-it.patch \
> > -   
> > file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch \
> >  "
> >
> > +# required by mesa-native on Ubuntu 18.04 with gcc 7.5 when DEBUG_BUILD 
> > enabled
> > +SRC_URI:append:class-native = " 
> > file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch"
> > +
> >   SRC_URI[sha256sum] = 
> > "b1f9c8fd08f2cae3adf83355bef4d2398e8025f44947332880f2d0066bdafa8c"
> >
> >   UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"
> >
> >
> >
>
> --
> Kai Kang
> Wind River Linux
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171946): 
https://lists.openembedded.org/g/openembedded-core/message/171946
Mute This Topic: https://lists.openembedded.org/mt/94012441/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] gcc: Allow -Wno-error=poison-system-directories to take effect

[Khem Raj]

On Thu, Oct 13, 2022 at 2:21 PM Peter Kjellerstedt
 wrote:
>
> > -Original Message-
> > From: Khem Raj 
> > Sent: den 13 oktober 2022 17:41
> > To: Peter Kjellerstedt 
> > Cc: Ross Burton ; Patches and discussions about the
> > oe-core layer 
> > Subject: Re: [OE-core] [PATCH] gcc: Allow -Wno-error=poison-system-
> > directories to take effect
> >
> > On Thu, Oct 13, 2022 at 7:38 AM Peter Kjellerstedt 
> >  wrote:
> > >
> > > > -Original Message-
> > > > From: Ross Burton 
> > > > Sent: den 13 oktober 2022 16:05
> > > > To: Peter Kjellerstedt 
> > > > Cc: Patches and discussions about the oe-core layer  > > > c...@lists.openembedded.org>
> > > > Subject: Re: [OE-core] [PATCH] gcc: Allow -Wno-error=poison-system-
> > > > directories to take effect
> > > >
> > > > Whilst this is a good fix, I’m horrified to ask why you need it…
> > >
> > > We have a recipe for skia. Somewhere in that mess of a build
> > > system it uses (gn), something adds -I/usr/include/freetype2,
> > > which results in an error with -Werror=poison-system-directories
> > > enabled (as it should). Now, to work around that problem, the
> > > recipe currently adds -I=/usr/include/freetype2, which means we
> > > know that the correct path is used. However, since the original
> > > -I/usr/include/freetype2 is still in the list of options, the
> > > error still triggers.
> > >
> > > Now, to fix the problem properly, skias's build files should be
> > > patched, but that is not my job. What I am working on is to get
> > > our recipes to build with Langdale. This means I can cut some
> > > corners and, e.g., disable errors and then hand off to the
> > > responsible team to fix the underlying problem at a time that
> > > suits them. Thus in this case I wanted to add
> > > -Wno-error=poison-system-directories for skia, which I then, to
> > > my surprise, noticed had no effect...
> >
> > from gcc recipe point of view, this fix is fine. however your use of
> > this seems to be a workaround that perhaps is better fixed in skia
>
> Oh, I'm well aware of that. As I said, my job at this stage is to get
> everything building with Langdale. And to achieve that, it is perfectly
> fine for me to, e.g., disable compiler errors. Once the platform
> builds, the respective code owners have the responsibility to actually
> correct their code to not generate the errors in the first place.

I hope you will inform the responsible and ask them to fix the problem.

>
> > because = syntax for sysroot works with gcc but may not work with
> > clang e.g. so you are being lucky here.
>
> We don't use clang so that is not a problem for us.
>
> > > //Peter
> > >
> > > > Ross
>
> //Peter
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171722): 
https://lists.openembedded.org/g/openembedded-core/message/171722
Mute This Topic: https://lists.openembedded.org/mt/94303421/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] gcc: Allow -Wno-error=poison-system-directories to take effect

[Khem Raj]

On Thu, Oct 13, 2022 at 7:38 AM Peter Kjellerstedt
 wrote:
>
> > -Original Message-
> > From: Ross Burton 
> > Sent: den 13 oktober 2022 16:05
> > To: Peter Kjellerstedt 
> > Cc: Patches and discussions about the oe-core layer  > c...@lists.openembedded.org>
> > Subject: Re: [OE-core] [PATCH] gcc: Allow -Wno-error=poison-system-
> > directories to take effect
> >
> > Whilst this is a good fix, I’m horrified to ask why you need it…
>
> We have a recipe for skia. Somewhere in that mess of a build
> system it uses (gn), something adds -I/usr/include/freetype2,
> which results in an error with -Werror=poison-system-directories
> enabled (as it should). Now, to work around that problem, the
> recipe currently adds -I=/usr/include/freetype2, which means we
> know that the correct path is used. However, since the original
> -I/usr/include/freetype2 is still in the list of options, the
> error still triggers.
>
> Now, to fix the problem properly, skias's build files should be
> patched, but that is not my job. What I am working on is to get
> our recipes to build with Langdale. This means I can cut some
> corners and, e.g., disable errors and then hand off to the
> responsible team to fix the underlying problem at a time that
> suits them. Thus in this case I wanted to add
> -Wno-error=poison-system-directories for skia, which I then, to
> my surprise, noticed had no effect...

from gcc recipe point of view, this fix is fine. however your use of
this seems to be a workaround that perhaps is better fixed in skia
because = syntax for sysroot works with gcc but may not work with
clang e.g. so you are being lucky here.

>
> //Peter
>
> >
> > Ross
> >
> > > On 13 Oct 2022, at 14:29, Peter Kjellerstedt via lists.openembedded.org
> >  wrote:
> > >
> > > The change in commit e903b29f (gcc-cross: pass
> > > -Werror=poison-system-directories to compiler stages) made it impossible
> > > to disable the error using -Wno-error=poison-system-directories.
> > >
> > > Signed-off-by: Peter Kjellerstedt 
> > > ---
> > > .../0002-gcc-poison-system-directories.patch  | 36 +--
> > > 1 file changed, 18 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/meta/recipes-devtools/gcc/gcc/0002-gcc-poison-system-
> > directories.patch b/meta/recipes-devtools/gcc/gcc/0002-gcc-poison-system-
> > directories.patch
> > > index bfec4477c1..5aa635b3d4 100644
> > > --- a/meta/recipes-devtools/gcc/gcc/0002-gcc-poison-system-
> > directories.patch
> > > +++ b/meta/recipes-devtools/gcc/gcc/0002-gcc-poison-system-
> > directories.patch
> > > @@ -1,4 +1,4 @@
> > > -From e1dbdcd0ea667bab4b551294354e04c6fe288ab6 Mon Sep 17 00:00:00 2001
> > > +From 99f1e61b2957226254a116fde7fd73bf07034012 Mon Sep 17 00:00:00 2001
> > > From: Khem Raj 
> > > Date: Mon, 8 Mar 2021 16:04:20 -0800
> > > Subject: [PATCH] gcc: poison-system-directories
> > > @@ -20,12 +20,12 @@ Signed-off-by: Khem Raj 
> > >  gcc/configure   | 19 +++
> > >  gcc/configure.ac| 16 
> > >  gcc/doc/invoke.texi |  9 +
> > > - gcc/gcc.cc  |  9 +++--
> > > + gcc/gcc.cc  | 15 ---
> > >  gcc/incpath.cc  | 21 +
> > > - 7 files changed, 86 insertions(+), 2 deletions(-)
> > > + 7 files changed, 91 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/gcc/common.opt b/gcc/common.opt
> > > -index 8a0dafc522d..0357868e22c 100644
> > > +index 8a0dafc52..0357868e2 100644
> > > --- a/gcc/common.opt
> > > +++ b/gcc/common.opt
> > > @@ -710,6 +710,10 @@ Wreturn-local-addr
> > > @@ -40,7 +40,7 @@ index 8a0dafc522d..0357868e22c 100644
> > >  Common Var(warn_shadow) Warning
> > >  Warn when one variable shadows another.  Same as -Wshadow=global.
> > > diff --git a/gcc/config.in b/gcc/config.in
> > > -index 64c27c9cfac..a693cb8a886 100644
> > > +index 64c27c9cf..a693cb8a8 100644
> > > --- a/gcc/config.in
> > > +++ b/gcc/config.in
> > > @@ -230,6 +230,16 @@
> > > @@ -61,7 +61,7 @@ index 64c27c9cfac..a693cb8a886 100644
> > > optimizer and back end) to be checked for dynamic type safety at
> > runtime.
> > > This is quite expensive. */
> > > diff --git a/gcc/configure b/gcc/configure
> > > -index 5ce0557719a..dc2d59701ad 100755
> > > +index 2b83acfb0..8bb97578c 100755
> > > --- a/gcc/configure
> > > +++ b/gcc/configure
> > 

Re: [OE-core] [kirkstone] core-image-weston doesn't build

[Khem Raj]

On Thu, Oct 13, 2022 at 2:59 AM Marta Rybczynska 
wrote:

> $ bitbake weston
> Loading cache: 100%
>
> |###|
> Time: 0:00:00
> Loaded 1640 entries from dependency cache.
> ERROR: Nothing PROVIDES 'weston'
> weston was skipped: missing required distro features 'wayland opengl'
> (not in DISTRO_FEATURES)
>
> Summary: There was 1 ERROR message, returning a non-zero exit code.
>
> I can add distro-features et al, just wondering if this image is
> expected to build by default with oe-core?


With poky yes but with vanilla oe-core it needs to enable OpenGL by default
for nodistro

>
>
> Regards,
> Marta
>
> On Thu, Oct 13, 2022 at 10:15 AM Alexander Kanavin
>  wrote:
> >
> > What happens when you run 'bitbake weston'?
> >
> > Alex
> >
> > On Thu, 13 Oct 2022 at 10:10, Marta Rybczynska 
> wrote:
> > >
> > >
> > >
> > > On Thu, 13 Oct 2022, 17:00 Alexandre Belloni, <
> alexandre.bell...@bootlin.com> wrote:
> > >>
> > >> On 13/10/2022 09:52:44+0200, Marta Rybczynska wrote:
> > >> > Hello all,
> > >> > I'm trying to build the core-image-weston in kirkstone to look into
> > >> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14926
> > >> >
> > >> > It turns out that the image does not build (oe-core
> > >> > e728d0965d6fda8ac54e065ca7bf7eb9da9a8170 with bitbake
> > >> > 6603c3e39f1cf746669ec6c9f0be8c6e6ece426e). I'm getting:
> > >> >
> > >> > $ bitbake core-image-weston
> > >> > Loading cache: 100%
> > >> >
> |###|
> > >> > Time: 0:00:00
> > >> > Loaded 1640 entries from dependency cache.
> > >> > NOTE: Resolving any missing task queue dependencies
> > >> > ERROR: Nothing RPROVIDES 'weston-xwayland' (but
> > >> > /oe-standalone/oe-core/meta/recipes-graphics/images/
> core-image-weston.bb
> > >> > RDEPENDS on
> > >> > or otherwise requires it)
> > >> > NOTE: Runtime target 'weston-xwayland' is unbuildable, removing...
> > >> > Missing or unbuildable dependency chain was: ['weston-xwayland']
> > >> > ERROR: Required build target 'core-image-weston' has no buildable
> providers.
> > >> > Missing or unbuildable dependency chain was: ['core-image-weston',
> > >> > 'weston-xwayland']
> > >> >
> > >> > Summary: There were 2 ERROR messages, returning a non-zero exit
> code.
> > >> >
> > >> > I can't find this one in bugzilla. Is it a known issue?
> > >> >
> > >>
> > >> Did you remove x11 from your DISTRO_FEATURES?
> > >
> > >
> > > No. This is a fresh clone. The only changes I have are in local.conf:
> DL_DIR and parallel build options. That's why I'm surprised.
> > >
> > > Regards
> > > Marta
> > >
> > >
> > >
> > >
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171704): 
https://lists.openembedded.org/g/openembedded-core/message/171704
Mute This Topic: https://lists.openembedded.org/mt/94299411/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] fix close_range fails unexpectedly in unprivileged process

[Khem Raj]

On Wed, Oct 12, 2022 at 5:41 PM Changqing Li 
wrote:

>
> On 10/8/22 15:13, Changqing Li wrote:
>
> On 9/30/22 17:50, Ross Burton wrote:
>
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> Yeah, this is a Docker issue. Fix your docker.
>
> Ross
>
> Hi,
>
> I know this is an docker issue, but this will block yocto build in old
> docker. I noticed we already
>
> have an local patch for glibc to fix similar issue. So, maybe this patch
> is also need.
>
>
> https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/glibc/glibc/0023-fix-create-thread-failed-in-unprivileged-process-BZ-.patch
> 
>
> BRs
>
>
These patches are addressing a corner case for supported systems and the
patches are not backports and it’s perhaps better to keep them local
Infact  I would suggest to send a patch to remove the above patch from core
glibc recipe instead

> Changqing
>
> ping
>
> On 30 Sep 2022, at 09:48, Changqing Li via lists.openembedded.org 
> 
>   
>  wrote:
>
> From: Changqing Li  
>
> After commit [1], start a unprivileged container (docker run without 
> --privileged),
> close file will fail.
>
> This is actually an docker issue, see [2]. But this issue will
> block yocto build in docker with glibc2.35+. so add this local patch.
>
> [1] 
> https://gitlab.gnome.org/GNOME/glib/-/commit/ce04a124040be091407e070280d86ca810bacb8c
>  
> 
> [2] https://github.com/moby/moby/issues/43595 
> 
>
> Signed-off-by: Changqing Li  
> 
> ---
> ...fails-unexpectedly-in-unprivileged-p.patch | 46 +++
> meta/recipes-core/glib-2.0/glib-2.0_2.72.3.bb 
> 
>  |  1 +
> 2 files changed, 47 insertions(+)
> create mode 100644 
> meta/recipes-core/glib-2.0/glib-2.0/0001-fix-close_range-fails-unexpectedly-in-unprivileged-p.patch
>
> diff --git 
> a/meta/recipes-core/glib-2.0/glib-2.0/0001-fix-close_range-fails-unexpectedly-in-unprivileged-p.patch
>  
> b/meta/recipes-core/glib-2.0/glib-2.0/0001-fix-close_range-fails-unexpectedly-in-unprivileged-p.patch
> new file mode 100644
> index 00..213ee7b11f
> --- /dev/null
> +++ 
> b/meta/recipes-core/glib-2.0/glib-2.0/0001-fix-close_range-fails-unexpectedly-in-unprivileged-p.patch
> @@ -0,0 +1,46 @@
> +From 0fb283b3b1e3b4958b985804cbc40b7bff8b0e65 Mon Sep 17 00:00:00 2001
> +From: Changqing Li  
> +Date: Fri, 30 Sep 2022 08:29:41 +
> +Subject: [PATCH] fix close_range fails unexpectedly in unprivileged process
> +
> +After change [1], start a unprivileged container (docker run without 
> --privileged),
> +close file may fail.
> +
> +This is actually an docker issue, see [2]. But this issue will
> +block yocto build in docker with glibc2.35+. so add this local patch.
> +
> +[1] 
> https://gitlab.gnome.org/GNOME/glib/-/commit/ce04a124040be091407e070280d86ca810bacb8c
>  
> 
> +[2] https://github.com/moby/moby/issues/43595 
> 
> +
> +Upstream-Status: Inappropriate [Rejected by upstream]
> +
> +Signed-off-by: Changqing Li  
> 
> +---
> + glib/gspawn.c | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/glib/gspawn.c b/glib/gspawn.c
> +index 0a2cbe5..83553a1 100644
> +--- a/glib/gspawn.c
>  b/glib/gspawn.c
> +@@ -1544,7 +1544,7 @@ safe_fdwalk_set_cloexec (int lowfd)
> +* fall back to safe_fdwalk(). Handle EINVAL in case `CLOSE_RANGE_CLOEXEC`
> +* is not supported. */
> +   int ret = close_range (lowfd, G_MAXUINT, CLOSE_RANGE_CLOEXEC);
> +-  if (ret == 0 || !(errno == ENOSYS || errno == EINVAL))
> ++  if (ret == 0 || !(errno == ENOSYS || errno == EINVAL || errno == EPERM))
> + return ret;
> 

Re: [OE-core] [PATCH v3] mesa: only apply patch to fix ALWAYS_INLINE for native

[Khem Raj]

On Wed, Oct 12, 2022 at 9:38 AM Ross Burton  wrote:

> > Ping.
>
> As per https://wiki.yoctoproject.org/wiki/Weekly_Status, master is frozen
> for release and RP is on vacation, so patches are being review/accumulated
> but are not merging just yet.
>

Can we publish the staging branch somewhere on poky-contrib or
oe-core-contrib

>
> Ross
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171675): 
https://lists.openembedded.org/g/openembedded-core/message/171675
Mute This Topic: https://lists.openembedded.org/mt/94012441/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 v2 1/3] kernel: classes: Extract savedefconfig to a class

[Khem Raj]

On Wed, Oct 12, 2022 at 9:36 AM Ross Burton  wrote:

> On 12 Oct 2022, at 08:18, Alex Kiernan via lists.openembedded.org
>  wrote:
> >
> > Move savedefconfig task to a class so we can reuse it in other recipes
> > which support it.
>
> There are three users of cml1 in oe-core: kernel, uboot, and busybox.
> Does busybox support savedefconfig?
>
> I’m thinking to avoid tiny classes we can just add this to cml1.bbclass
> and make it print a decent error message if it doesn’t work.
>

I agree I think it should be there for all kconfig users and they can strub
it in recipe if needed

>
> Ross
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171673): 
https://lists.openembedded.org/g/openembedded-core/message/171673
Mute This Topic: https://lists.openembedded.org/mt/94276340/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] perf: Depend on native setuptools3

[Khem Raj]

perf has need for python setuptools when scripting is enabled
from 6.0.0 onwards it seems to throw an explicit error

Signed-off-by: Khem Raj 
Cc: Bruce Ashfield 
---
 meta/recipes-kernel/perf/perf.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 31bc04635d..c1b0bd22d8 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -13,7 +13,7 @@ PR = "r9"
 
 PACKAGECONFIG ??= "scripting tui libunwind"
 PACKAGECONFIG[dwarf] = ",NO_DWARF=1"
-PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl python3"
+PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl python3 
python3-setuptools-native"
 # gui support was added with kernel 3.6.35
 # since 3.10 libnewt was replaced by slang
 # to cover a wide range of kernel we add both dependencies
-- 
2.38.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171591): 
https://lists.openembedded.org/g/openembedded-core/message/171591
Mute This Topic: https://lists.openembedded.org/mt/94251905/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 2/3] perf: make scripting depend on setuptools3

[Khem Raj]

On Fri, Oct 7, 2022 at 8:00 AM Peter Kjellerstedt
 wrote:
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Bruce Ashfield
> > Sent: den 6 oktober 2022 16:02
> > To: Ross Burton 
> > Cc: Richard Purdie ; openembedded-
> > c...@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH 2/3] perf: make scripting depend on
> > setuptools3
> >
> > On Thu, Oct 6, 2022 at 9:43 AM Ross Burton  wrote:
> > >
> > > On 6 Oct 2022, at 14:29, Bruce Ashfield  wrote:
> > > > I'm not particularly concerned if the extra RDEPENDS arrives with
> > > > this, since if it is acceptable for other packages inheriting the
> > > > setuptools (I thought it was build support only!), it really should be
> > > > ok for perf as well. In particular since perf is debug/optional. Or am
> > > > I missing something there ?
> > >
> > > With this change the base perf package will always runtime-depend on
> > > python3, even if perf-python isn’t installed.  That sounds suboptimal.
> > >
> >
> > But is triggered on the 'scripting' packageconfig, which does mean we
> > want the support, so it is at least somewhat conditional .. but yes, I
> > agree that once we've built and packaged, it does make sense to keep
> > the python dependencies in the dedicated package.
> >
> > Let me re-work this and do the remove of the RDEPENDS and send a v2.
> >
> > Bruce
> >
> > > Ross
>
> To me it sounds as what setuptools3-base.bbclass really should to is
> something like:
>
> FOOBAR ??= "${PN}"
> RDEPENDS:${FOOBAR}:append:class-target = " ${PYTHON_PN}-core"
> ...
> FILES:${FOOBAR} += "${libdir}/* ${libdir}/${PYTHON_DIR}/*"
>
> so that the typical Python only recipes continue to just inherit
> setuptools3, but recipes that produce other packages than the
> Python package can do something like:
>
> FOOBAR = "${PYTHON_PN}-${PN}"
>
> Unfortunately this does not work as it results in a gazillion
> warnings like:
>
> WARNING: .../meta-oe/recipes-support/libiio/libiio_git.bb: Variable key 
> FILES:${PN}-${PYTHON_PN} (${PYTHON_SITEPACKAGES_DIR}) replaces original key 
> FILES:libiio-python3 ( ${libdir}/* ${libdir}/${PYTHON_DIR}/*).
> WARNING: .../meta-oe/recipes-support/libiio/libiio_git.bb: Variable key 
> RDEPENDS:${PN}-${PYTHON_PN} (${PN} ${PYTHON_PN}-ctypes ${PYTHON_PN}-stringold 
> ${PYTHON_PN}-core) replaces original key RDEPENDS:libiio-python3 ( 
> ${PYTHON_PN}-core).
>
> (I chose libiio as it is an example of another recipes that currently
> does RDEPENDS:${PN}:remove = "${PYTHON_PN}-core" to counteract what
> setuptools3-base.bbclass does).
>

Ran into this today too. I think you dont need all the bells and
whistles of setuptools3 class. Adding

DEPENDS += "python3-setuptools-native"

should get the job done.

> :(
>
> //Peter
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171590): 
https://lists.openembedded.org/g/openembedded-core/message/171590
Mute This Topic: https://lists.openembedded.org/mt/94118767/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] ptests: Mark ptest-runner as rdepend instead of rrecommends

[Khem Raj]

This ensures all runtime deependencies eg. perl-modules recommendations
are added to dependencies correctly

see [1]

[1] 
https://git.yoctoproject.org/poky/commit/?h=master=4705dd264681d908f144dd4d9bf1f6175f68d8b9

Signed-off-by: Khem Raj 
Cc: Ross Burton 
---
 meta/classes-recipe/ptest.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes-recipe/ptest.bbclass 
b/meta/classes-recipe/ptest.bbclass
index 0383206a6d..36266ec161 100644
--- a/meta/classes-recipe/ptest.bbclass
+++ b/meta/classes-recipe/ptest.bbclass
@@ -23,10 +23,9 @@ PTEST_ENABLED = "${@bb.utils.contains('DISTRO_FEATURES', 
'ptest', '1', '0', d)}"
 PTEST_ENABLED:class-native = ""
 PTEST_ENABLED:class-nativesdk = ""
 PTEST_ENABLED:class-cross-canadian = ""
-RDEPENDS:${PN}-ptest += "${PN}"
+RDEPENDS:${PN}-ptest += "${PN} ptest-runner"
 RDEPENDS:${PN}-ptest:class-native = ""
 RDEPENDS:${PN}-ptest:class-nativesdk = ""
-RRECOMMENDS:${PN}-ptest += "ptest-runner"
 
 PACKAGES =+ "${@bb.utils.contains('PTEST_ENABLED', '1', '${PN}-ptest', '', d)}"
 
-- 
2.38.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171585): 
https://lists.openembedded.org/g/openembedded-core/message/171585
Mute This Topic: https://lists.openembedded.org/mt/94246720/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] [master|langdale|kirkstone][PATCH] qemu-native: Add PACKAGECONFIG option for jack

[Khem Raj]

On Mon, Oct 10, 2022 at 12:27 PM Jeremy Puhlman  wrote:
>
> Source: MontaVista Software, LLC
> MR: 122826
> Type: Defect Fix
> Disposition:  Needs submitting to poky

Above seems out of context, since you are submitting it upstream here.

> ChangeID: ecf4ddeb82db6fbb5c6c803e5e80c333587b9c9c
> Description:
>
> With libjack-devel or jack-audio-connection-kit-devel, qemu-native
> detects the library/header and tries to build with it. Since its
> missing from the sysroot, it fails to build.
>
>  -O2 -fPIE -D_REENTRANT -Wno-undef -MD -MQ libcommon.fa.p/audio_jackaudio.c.o
> -MF libcommon.fa.p/audio_jackaudio.c.o.d -o libcommon.fa.p/audio_jackaudio.c.o
> -c ../qemu-6.2.0/audio/jackaudio.c
> | ../qemu-6.2.0/audio/jackaudio.c:34:10: fatal error: jack/jack.h: No such 
> file
> or directory
> |34 | #include 
> |   |  ^
> | compilation terminated.
>
> Signed-off-by: Jeremy A. Puhlman 
> ---
>  meta/recipes-devtools/qemu/qemu.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index 612abd240a..711982ba8d 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -198,6 +198,7 @@ PACKAGECONFIG[rdma] = "--enable-rdma,--disable-rdma"
>  PACKAGECONFIG[vde] = "--enable-vde,--disable-vde"
>  PACKAGECONFIG[slirp] = "--enable-slirp=internal,--disable-slirp"
>  PACKAGECONFIG[brlapi] = "--enable-brlapi,--disable-brlapi"
> +PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack,"
>
>  INSANE_SKIP:${PN} = "arch"
>
> --
> 2.35.4
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171581): 
https://lists.openembedded.org/g/openembedded-core/message/171581
Mute This Topic: https://lists.openembedded.org/mt/94244017/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] musl: Upgrade to latest master

[Khem Raj]

Following changes are part of this SRCREV uprev

* dc9285ad fix error cases in gethostbyaddr_r
* f9827fc7 remove impossible error case from gethostbyname2_r
* f081d533 fix return value of gethostnbyname[2]_r on result not found
* 1e7fb12f dns: treat names rejected by res_mkquery as nonexistent rather than 
error
* 001c1afb res_mkquery: error out on consecutive final dots in name
* 3ad3fa96 fix thread leak on timer_create(SIGEV_THREAD) failure
* bf14ef19 re-enable vdso clock_gettime on arm (32-bit) with workaround
* 6f3ead0a process DT_RELR relocations in ldso-startup/static-pie
* 25085c85 fix fwprintf missing output to open_wmemstream FILEs
* a636fd63 dns: fail if ipv6 is disabled and resolv.conf has only v6 nameserves
* 996b6154 use kernel-provided AT_MINSIGSTKSZ for sysconf(_SC_[MIN]SIGSTKSZ)
* 25340a93 add sysconf keys/values for signal stack size
* d8fddb96 fix fallback when ipv6 is disabled but resolv.conf has v6 nameserves
* d4f987e4 epoll_create: fail with EINVAL if size is non-positive
* 2e5fff43 use alt signal stack when present for implementation-internal signals
* 379b1821 ldso: make exit condition clearer in fixup_rpath

Signed-off-by: Khem Raj 
---
 meta/recipes-core/musl/musl_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/musl/musl_git.bb 
b/meta/recipes-core/musl/musl_git.bb
index 97c27eba4a..a72d87ea6f 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -4,7 +4,7 @@
 require musl.inc
 inherit linuxloader
 
-SRCREV = "37e18b7bf307fa4a8c745feebfcba54a0ba74f30"
+SRCREV = "dc9285ad1dc19349c407072cc48ba70dab86de45"
 
 BASEVER = "1.2.3"
 
-- 
2.38.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171478): 
https://lists.openembedded.org/g/openembedded-core/message/171478
Mute This Topic: https://lists.openembedded.org/mt/94148191/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] core-image-sato: install virtio input for Qemu targets

[Khem Raj]

On Wed, Oct 5, 2022 at 8:01 AM Thomas Perrot via
lists.openembedded.org
 wrote:
>
> Otherwise, it isn't possible to interact with the UI.

I wonder if it should be in the MACHINE_EXTRA_RRECOMMENDS in machine
configs, it will help a wide range of users who may be using
graphical images.

>
> Signed-off-by: Thomas Perrot 
> ---
>  meta/recipes-sato/images/core-image-sato.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-sato/images/core-image-sato.bb 
> b/meta/recipes-sato/images/core-image-sato.bb
> index e63a229d1257..0e37c15097b3 100644
> --- a/meta/recipes-sato/images/core-image-sato.bb
> +++ b/meta/recipes-sato/images/core-image-sato.bb
> @@ -12,6 +12,8 @@ inherit core-image
>  TOOLCHAIN_HOST_TASK:append = " nativesdk-intltool nativesdk-glib-2.0"
>  TOOLCHAIN_HOST_TASK:remove:task-populate-sdk-ext = " nativesdk-intltool 
> nativesdk-glib-2.0"
>
> +IMAGE_INSTALL:append:qemuall = " kernel-module-virtio-input"
> +
>  QB_MEM = '${@bb.utils.contains("DISTRO_FEATURES", "opengl", "-m 512", "-m 
> 256", d)}'
>  QB_MEM:qemuarmv5 = "-m 256"
>  QB_MEM:qemumips = "-m 256"
> --
> 2.37.3
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171471): 
https://lists.openembedded.org/g/openembedded-core/message/171471
Mute This Topic: https://lists.openembedded.org/mt/94137249/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 4/5] piglit: upgrade to latest revision

[Khem Raj]

On Tue, Oct 4, 2022 at 7:15 AM Ross Burton  wrote:
>
> On 4 Oct 2022, at 15:08, Khem Raj  wrote:
> >
> > On Tue, Oct 4, 2022 at 6:39 AM Ross Burton  wrote:
> >>
> >> On 4 Oct 2022, at 14:36, Khem Raj via lists.openembedded.org 
> >>  wrote:
> >>> How does debugging piglet looks like after this change ? I wonder if we 
> >>> can reduce debug info by
> >>> Using something like -g1 maybe a good middle ground
> >>
> >> The binaries have been stripped since 2016, this change simply stops 
> >> do_package from trying to split/strip the debug symbols.  There’s 2GB of 
> >> already-stripped binaries to process, which on my machine takes over a 
> >> minute.
> >
> > yeah understood, I was trying to see if we can make it optimize a bit
> > while you were here.
>
> Turning on any form of debug would make that 2GB more like 3GB…

hmm yeah I guess. Ignore me.

>
> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171400): 
https://lists.openembedded.org/g/openembedded-core/message/171400
Mute This Topic: https://lists.openembedded.org/mt/94110619/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 4/5] piglit: upgrade to latest revision

[Khem Raj]

On Tue, Oct 4, 2022 at 6:39 AM Ross Burton  wrote:
>
> On 4 Oct 2022, at 14:36, Khem Raj via lists.openembedded.org 
>  wrote:
> > How does debugging piglet looks like after this change ? I wonder if we can 
> > reduce debug info by
> > Using something like -g1 maybe a good middle ground
>
> The binaries have been stripped since 2016, this change simply stops 
> do_package from trying to split/strip the debug symbols.  There’s 2GB of 
> already-stripped binaries to process, which on my machine takes over a minute.

yeah understood, I was trying to see if we can make it optimize a bit
while you were here.

>
> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171397): 
https://lists.openembedded.org/g/openembedded-core/message/171397
Mute This Topic: https://lists.openembedded.org/mt/94110619/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 4/5] piglit: upgrade to latest revision

[Khem Raj]

On Tue, Oct 4, 2022 at 3:51 AM Ross Burton  wrote:

> Also disable any attempt at debug splitting/stripping.  Piglit installs
> over 2GB of files which we install stripped, so the action of attempting
> to split/strip takes a long time and achieves nothing.
>
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-graphics/piglit/piglit_git.bb | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-graphics/piglit/piglit_git.bb
> b/meta/recipes-graphics/piglit/piglit_git.bb
> index f758208c6bc..c9cf5795e99 100644
> --- a/meta/recipes-graphics/piglit/piglit_git.bb
> +++ b/meta/recipes-graphics/piglit/piglit_git.bb
> @@ -14,7 +14,7 @@ SRC_URI = "git://
> gitlab.freedesktop.org/mesa/piglit.git;protocol=https;branch=ma
> "
>  UPSTREAM_CHECK_COMMITS = "1"
>
> -SRCREV = "265896c86f90cb72e8f218ba6a3617fca8b9a1e3"
> +SRCREV = "80465078a0ae8f12411db66850ee14f017962fa7"
>  # (when PV goes above 1.0 remove the trailing r)
>  PV = "1.0+gitr${SRCPV}"
>
> @@ -52,8 +52,10 @@ do_configure:prepend() {
> fi
>  }
>
> -# Forcibly strip because Piglit is *huge*
> +# Forcibly strip because Piglit is *huge*, and don't bother trying to
> split/strip the result.
>  OECMAKE_TARGET_INSTALL = "install/strip"
> +INHIBIT_PACKAGE_STRIP = "1"
> +INHIBIT_PACKAGE_DEBUG_SPLIT = "1"


How does debugging piglet looks like after this change ? I wonder if we can
reduce debug info by
Using something like -g1 maybe a good middle ground


>
>  RDEPENDS:${PN} = "waffle waffle-bin python3 python3-mako python3-json \
> python3-misc \
> --
> 2.34.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171394): 
https://lists.openembedded.org/g/openembedded-core/message/171394
Mute This Topic: https://lists.openembedded.org/mt/94110619/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] openssl: Add missing perl module runtime dependencies for ptests

[Khem Raj]

On Sat, Oct 1, 2022 at 3:29 PM Khem Raj  wrote:
>
>
>
> On Sat, Oct 1, 2022 at 1:01 PM Ross Burton  wrote:
>>
>> > OK my RRECOMMENDS:perl-modules are fine similar to Ross, however they
>> > does not get pulled into final image when openssl-ptest is added to
>> > IMAGE_INSTALL
>>
>>
>> That’s definitely worth looking into. This isn’t the solution, assuming 
>> you’re not disabling recommendations in your image recipe.
>
>
> Core-image-ptest works so hmm I don’t know what’s wrong with my image
>

I think the issue seems with any image using opkg backend and adding

IMAGE_FEATURES += "ptest-pkgs"

in local.conf

DISTRO_FEATURES += "ptest"

It does not even bring ptest-runner which is in RRECOMMENDS of every
ptest package.

The core-image-ptest work perhaps because they explicitly specify
certain ptest packages and they bring in the needed deps


>>
>>
>> Ross
>> 
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171374): 
https://lists.openembedded.org/g/openembedded-core/message/171374
Mute This Topic: https://lists.openembedded.org/mt/94010252/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 1/1] ltp: Update to 20220930

[Khem Raj]

On Mon, Oct 3, 2022 at 11:49 AM Petr Vorel  wrote:
>
> Hi Alexandre,
>
> ...
> > > Hi,
> > >
> > > could you please test this patchset?
> >
> > This causes the following warning:
> >
> > ltp-20220930-r0 do_package_qa: QA Issue: File 
> > /opt/ltp/testcases/open_posix_testsuite/config.log in package ltp contains 
> > reference to TMPDIR
>
> Thanks for a testing. I wonder why this is problem to use TMPDIR.
> Also, there already has been many TMPDIR references before:
>
> $ git grep -l TMPDIR 20220527 | wc -l
> 139
>
> $ git grep -l TMPDIR 20220930 | wc -l
> 141
>
> And the same number of them in open posix:
>
> $ git grep -l TMPDIR 20220527 testcases/open_posix_testsuite/ | wc -l
> 1
>
> $ git grep -l TMPDIR 20220930 testcases/open_posix_testsuite/ | wc -l
> 1

I think the problem is that these references are inside the config.log
file which is getting installed.
I wonder if this log file should be installed as part of testsuite on
target or not. If this file
/opt/ltp/testcases/open_posix_testsuite/config.log is
not needed for running the testsuite then perhaps its better to just
delete it from ${D} in do_install
and that will fix it.

>
> Kind regards,
> Petr
>
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5988/steps/12/logs/warnings

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171367): 
https://lists.openembedded.org/g/openembedded-core/message/171367
Mute This Topic: https://lists.openembedded.org/mt/94056329/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] openssl: Add missing perl module runtime dependencies for ptests

[Khem Raj]

On Sat, Oct 1, 2022 at 1:01 PM Ross Burton  wrote:

> > OK my RRECOMMENDS:perl-modules are fine similar to Ross, however they
> > does not get pulled into final image when openssl-ptest is added to
> > IMAGE_INSTALL
>
>
> That’s definitely worth looking into. This isn’t the solution, assuming
> you’re not disabling recommendations in your image recipe.


Core-image-ptest works so hmm I don’t know what’s wrong with my image


>
> Ross
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171350): 
https://lists.openembedded.org/g/openembedded-core/message/171350
Mute This Topic: https://lists.openembedded.org/mt/94010252/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] openssl: Add missing perl module runtime dependencies for ptests

[Khem Raj]

Thanks Alex, I will rework it.

On Fri, Sep 30, 2022 at 1:44 PM Alexandre Belloni
 wrote:
>
> Hello,
>
> This caused many issues on the autobuilders, similar to those:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5982/steps/11/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/3796/steps/11/logs/stdio
>
> On 29/09/2022 21:16:14-0700, Khem Raj wrote:
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/recipes-connectivity/openssl/openssl_3.0.5.bb | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-connectivity/openssl/openssl_3.0.5.bb 
> > b/meta/recipes-connectivity/openssl/openssl_3.0.5.bb
> > index 04aff04fab..119e58ed24 100644
> > --- a/meta/recipes-connectivity/openssl/openssl_3.0.5.bb
> > +++ b/meta/recipes-connectivity/openssl/openssl_3.0.5.bb
> > @@ -243,7 +243,16 @@ CONFFILES:openssl-conf = 
> > "${sysconfdir}/ssl/openssl.cnf"
> >
> >  RRECOMMENDS:libcrypto += "openssl-conf ${PN}-ossl-module-legacy"
> >  RDEPENDS:${PN}-misc = "perl"
> > -RDEPENDS:${PN}-ptest += "openssl-bin perl perl-modules bash sed"
> > +RDEPENDS:${PN}-ptest += "bash sed openssl-bin \
> > + perl perl-modules \
> > + perl-module-file-spec-functions \
> > + perl-module-findbin perl-module-harness 
> > perl-module-tap-base \
> > + perl-module-tap-object 
> > perl-module-tap-parser-sourcehandler-executable \
> > + perl-module-tap-formatter-file 
> > perl-module-tap-formatter-session \
> > + perl-module-tap-formatter-base 
> > perl-module-tap-parser \
> > + perl-module-tap-parser-scheduler 
> > perl-module-test-more \
> > + perl-module-pod-text perl-module-encode-encoding \
> > + "
> >
> >  RDEPENDS:${PN}-bin += "openssl-conf"
> >
> > --
> > 2.37.3
> >
>
> >
> > 
> >
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171245): 
https://lists.openembedded.org/g/openembedded-core/message/171245
Mute This Topic: https://lists.openembedded.org/mt/94010252/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] openssl: Add missing perl module runtime dependencies for ptests

[Khem Raj]

On Fri, Sep 30, 2022 at 10:10 AM Khem Raj  wrote:
>
> On Fri, Sep 30, 2022 at 10:08 AM Khem Raj  wrote:
> >
> > On Fri, Sep 30, 2022 at 10:01 AM Ross Burton  wrote:
> > >
> > >
> > > > On 30 Sep 2022, at 17:42, Khem Raj  wrote:
> > > > > Good point I will check in think it worked fine with glibc but not 
> > > > > with musl based images I see that Perl-modules is fully empty in 
> > > > > packages-split area so soMething does not add up
> > > >
> > > > It will be empty as it’s a metapackage, but it should have lots of 
> > > > rrecommends.
> > > >
> > > > Right that was the point the folder should not have been empty it 
> > > > should have had those rdepends control files
> > >
> > >
> > > My perl-modules pkgdata built with musl:
> > >
> > > RRECOMMENDS:perl-modules: perl-module-cpan perl-module-unicore 
> > > perl-module-b perl-module-compress-raw-bzip2 
> > > perl-module-compress-raw-zlib perl-module-cwd perl-module-data-dumper 
> > > perl-module-devel-peek perl-module-digest-md5 perl-module-digest-sha 
> > > perl-module-encode-byte perl-module-encode-cn […]
> > >
> > > Can you retest?  Unless you’re running in a no-recommends build I can’t 
> > > see how this can be.
> > >
> > > Arguably, perl-modules should depends on the packages, otherwise it 
> > > totally breaks in no-recommends environments.  If you install 
> > > perl-modules you want the entire library, not just a fraction of it.
> >
> > are you building with opkg ?
>
> and here is my list of bad recommendations
>
> BAD_RECOMMENDATIONS += "eudev-hwdb udev-hwdb libmodule-build-perl"
>

OK my RRECOMMENDS:perl-modules are fine similar to Ross, however they
does not get pulled into final image when openssl-ptest is added to
IMAGE_INSTALL

> >
> > >
> > > Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171232): 
https://lists.openembedded.org/g/openembedded-core/message/171232
Mute This Topic: https://lists.openembedded.org/mt/94010252/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] openssl: Add missing perl module runtime dependencies for ptests

[Khem Raj]

On Fri, Sep 30, 2022 at 10:08 AM Khem Raj  wrote:
>
> On Fri, Sep 30, 2022 at 10:01 AM Ross Burton  wrote:
> >
> >
> > > On 30 Sep 2022, at 17:42, Khem Raj  wrote:
> > > > Good point I will check in think it worked fine with glibc but not with 
> > > > musl based images I see that Perl-modules is fully empty in 
> > > > packages-split area so soMething does not add up
> > >
> > > It will be empty as it’s a metapackage, but it should have lots of 
> > > rrecommends.
> > >
> > > Right that was the point the folder should not have been empty it should 
> > > have had those rdepends control files
> >
> >
> > My perl-modules pkgdata built with musl:
> >
> > RRECOMMENDS:perl-modules: perl-module-cpan perl-module-unicore 
> > perl-module-b perl-module-compress-raw-bzip2 perl-module-compress-raw-zlib 
> > perl-module-cwd perl-module-data-dumper perl-module-devel-peek 
> > perl-module-digest-md5 perl-module-digest-sha perl-module-encode-byte 
> > perl-module-encode-cn […]
> >
> > Can you retest?  Unless you’re running in a no-recommends build I can’t see 
> > how this can be.
> >
> > Arguably, perl-modules should depends on the packages, otherwise it totally 
> > breaks in no-recommends environments.  If you install perl-modules you want 
> > the entire library, not just a fraction of it.
>
> are you building with opkg ?

and here is my list of bad recommendations

BAD_RECOMMENDATIONS += "eudev-hwdb udev-hwdb libmodule-build-perl"

>
> >
> > Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171231): 
https://lists.openembedded.org/g/openembedded-core/message/171231
Mute This Topic: https://lists.openembedded.org/mt/94010252/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] openssl: Add missing perl module runtime dependencies for ptests

[Khem Raj]

On Fri, Sep 30, 2022 at 10:01 AM Ross Burton  wrote:
>
>
> > On 30 Sep 2022, at 17:42, Khem Raj  wrote:
> > > Good point I will check in think it worked fine with glibc but not with 
> > > musl based images I see that Perl-modules is fully empty in 
> > > packages-split area so soMething does not add up
> >
> > It will be empty as it’s a metapackage, but it should have lots of 
> > rrecommends.
> >
> > Right that was the point the folder should not have been empty it should 
> > have had those rdepends control files
>
>
> My perl-modules pkgdata built with musl:
>
> RRECOMMENDS:perl-modules: perl-module-cpan perl-module-unicore perl-module-b 
> perl-module-compress-raw-bzip2 perl-module-compress-raw-zlib perl-module-cwd 
> perl-module-data-dumper perl-module-devel-peek perl-module-digest-md5 
> perl-module-digest-sha perl-module-encode-byte perl-module-encode-cn […]
>
> Can you retest?  Unless you’re running in a no-recommends build I can’t see 
> how this can be.
>
> Arguably, perl-modules should depends on the packages, otherwise it totally 
> breaks in no-recommends environments.  If you install perl-modules you want 
> the entire library, not just a fraction of it.

are you building with opkg ?

>
> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171230): 
https://lists.openembedded.org/g/openembedded-core/message/171230
Mute This Topic: https://lists.openembedded.org/mt/94010252/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] openssl: Add missing perl module runtime dependencies for ptests

[Khem Raj]

On Fri, Sep 30, 2022 at 9:30 AM Ross Burton  wrote:

>
>
> > On 30 Sep 2022, at 17:03, Khem Raj via lists.openembedded.org  gmail@lists.openembedded.org> wrote:
> >
> > Good point I will check in think it worked fine with glibc but not with
> musl based images I see that Perl-modules is fully empty in packages-split
> area so soMething does not add up
>
> It will be empty as it’s a metapackage, but it should have lots of
> rrecommends.


Right that was the point the folder should not have been empty it should
have had those rdepends control files


>
> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171228): 
https://lists.openembedded.org/g/openembedded-core/message/171228
Mute This Topic: https://lists.openembedded.org/mt/94010252/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] openssl: Add missing perl module runtime dependencies for ptests

[Khem Raj]

On Fri, Sep 30, 2022 at 3:37 AM Ross Burton  wrote:

>
>
> > On 30 Sep 2022, at 11:16, Ross Burton via lists.openembedded.org
>  wrote:
> >
> > On 30 Sep 2022, at 05:16, Khem Raj via lists.openembedded.org  gmail@lists.openembedded.org> wrote:
> >> -RDEPENDS:${PN}-ptest += "openssl-bin perl perl-modules bash sed"
> >> +RDEPENDS:${PN}-ptest += "bash sed openssl-bin \
> >> + perl perl-modules \
> >
> > I thought the point of perl-modules was to depend on the entire standard
> library, so isn’t this a bug in perl-modules?
>
> My perl-modules RRECOMMENDS on, eg, perl-module-tap-parser.
>
> Are you building an image with recommendations turned off?


Good point I will check in think it worked fine with glibc but not with
musl based images I see that Perl-modules is fully empty in packages-split
area so soMething does not add up

>
>
> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171226): 
https://lists.openembedded.org/g/openembedded-core/message/171226
Mute This Topic: https://lists.openembedded.org/mt/94010252/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] openssl: Add missing perl module runtime dependencies for ptests

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/recipes-connectivity/openssl/openssl_3.0.5.bb | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_3.0.5.bb 
b/meta/recipes-connectivity/openssl/openssl_3.0.5.bb
index 04aff04fab..119e58ed24 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.0.5.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.0.5.bb
@@ -243,7 +243,16 @@ CONFFILES:openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
 
 RRECOMMENDS:libcrypto += "openssl-conf ${PN}-ossl-module-legacy"
 RDEPENDS:${PN}-misc = "perl"
-RDEPENDS:${PN}-ptest += "openssl-bin perl perl-modules bash sed"
+RDEPENDS:${PN}-ptest += "bash sed openssl-bin \
+ perl perl-modules \
+ perl-module-file-spec-functions \
+ perl-module-findbin perl-module-harness 
perl-module-tap-base \
+ perl-module-tap-object 
perl-module-tap-parser-sourcehandler-executable \
+ perl-module-tap-formatter-file 
perl-module-tap-formatter-session \
+ perl-module-tap-formatter-base perl-module-tap-parser 
\
+ perl-module-tap-parser-scheduler 
perl-module-test-more \
+ perl-module-pod-text perl-module-encode-encoding \
+ "
 
 RDEPENDS:${PN}-bin += "openssl-conf"
 
-- 
2.37.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171204): 
https://lists.openembedded.org/g/openembedded-core/message/171204
Mute This Topic: https://lists.openembedded.org/mt/94010252/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] linux-yocto/5.19: fix gcc-11 warning

[Khem Raj]

Ok, thanks.

On Tue, Sep 27, 2022 at 12:24 PM Bruce Ashfield 
wrote:

> 11. The full upstream commit is:
>
> Author: Florian Fainelli 
> Date:   Sun Jul 31 19:51:09 2022 -0700
> libbpf: Initialize err in probe_map_create
>
>GCC-11 warns about the possibly unitialized err variable in
> probe_map_create:
>
>
> libbpf_probes.c: In function 'probe_map_create':
> libbpf_probes.c:361:38: error: 'err' may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
>   361 | return fd < 0 && err == exp_err ? 1 : 0;
>   |  ^~
>
> Fixes: 878d8def0603 ("libbpf: Rework feature-probing APIs")
> Signed-off-by: Florian Fainelli 
>
> Bruce
>
> On Tue, Sep 27, 2022 at 3:14 PM Khem Raj  wrote:
> >
> > gcc11 or 12 ?
> >
> > On Tue, Sep 27, 2022 at 12:05 PM Bruce Ashfield
> >  wrote:
> > >
> > > From: Bruce Ashfield 
> > >
> > > Integrating the following commit(s) to linux-yocto/5.19:
> > >
> > > 65a9a22786a6 libbpf: Initialize err in probe_map_create
> > >
> > > Signed-off-by: Bruce Ashfield 
> > > ---
> > >
> > > Ross identified this change as worth backporting to fix some
> > > gcc-11 warnings. I've been soaking it for a bit, and haven't
> > > seen any issues.
> > >
> > > Bruce
> > >
> > >  .../linux/linux-yocto-rt_5.19.bb  |  2 +-
> > >  .../linux/linux-yocto-tiny_5.19.bb|  2 +-
> > >  meta/recipes-kernel/linux/linux-yocto_5.19.bb | 20
> +--
> > >  3 files changed, 12 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
> b/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
> > > index 17ae94066c..b3e9fbae62 100644
> > > --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
> > > +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
> > > @@ -11,7 +11,7 @@ python () {
> > >  raise bb.parse.SkipRecipe("Set
> PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
> > >  }
> > >
> > > -SRCREV_machine ?= "359292dcf3fc078090666dc327d233695310"
> > > +SRCREV_machine ?= "bc8af638c00f28a46e77e34056079087638f6e65"
> > >  SRCREV_meta ?= "350b544d077955b599b54ab364f6227d96a90455"
> > >
> > >  SRC_URI = "git://
> git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine
> <http://git.yoctoproject.org/linux-yocto.git;branch=$%7BKBRANCH%7D;name=machine>
> \
> > > diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
> b/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
> > > index c18278ad79..466b7063b4 100644
> > > --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
> > > +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
> > > @@ -14,7 +14,7 @@ DEPENDS += "openssl-native util-linux-native"
> > >  KMETA = "kernel-meta"
> > >  KCONF_BSP_AUDIT_LEVEL = "2"
> > >
> > > -SRCREV_machine ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> > > +SRCREV_machine ?= "65a9a22786a6710fc7b4edb7cfae80dd83f591f1"
> > >  SRCREV_meta ?= "350b544d077955b599b54ab364f6227d96a90455"
> > >
> > >  PV = "${LINUX_VERSION}+git${SRCPV}"
> > > diff --git a/meta/recipes-kernel/linux/linux-yocto_5.19.bb
> b/meta/recipes-kernel/linux/linux-yocto_5.19.bb
> > > index 4fc1ae9245..f882972e35 100644
> > > --- a/meta/recipes-kernel/linux/linux-yocto_5.19.bb
> > > +++ b/meta/recipes-kernel/linux/linux-yocto_5.19.bb
> > > @@ -13,16 +13,16 @@ KBRANCH:qemux86  ?= "v5.19/standard/base"
> > >  KBRANCH:qemux86-64 ?= "v5.19/standard/base"
> > >  KBRANCH:qemumips64 ?= "v5.19/standard/mti-malta64"
> > >
> > > -SRCREV_machine:qemuarm ?= "9111e441d26961e67bef7866919c51b27e794bac"
> > > -SRCREV_machine:qemuarm64 ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> > > -SRCREV_machine:qemumips ?= "5f89b6548b6665f3ebec11266f2c7db2793129da"
> > > -SRCREV_machine:qemuppc ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> > > -SRCREV_machine:qemuriscv64 ?=
> "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> > > -SRCREV_machine:qemuriscv32 ?=
> "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> > > -SRCREV_machine:qemux86 ?= "44a446e91ac

Re: [OE-core] [PATCH] linux-yocto/5.19: fix gcc-11 warning

[Khem Raj]

gcc11 or 12 ?

On Tue, Sep 27, 2022 at 12:05 PM Bruce Ashfield
 wrote:
>
> From: Bruce Ashfield 
>
> Integrating the following commit(s) to linux-yocto/5.19:
>
> 65a9a22786a6 libbpf: Initialize err in probe_map_create
>
> Signed-off-by: Bruce Ashfield 
> ---
>
> Ross identified this change as worth backporting to fix some
> gcc-11 warnings. I've been soaking it for a bit, and haven't
> seen any issues.
>
> Bruce
>
>  .../linux/linux-yocto-rt_5.19.bb  |  2 +-
>  .../linux/linux-yocto-tiny_5.19.bb|  2 +-
>  meta/recipes-kernel/linux/linux-yocto_5.19.bb | 20 +--
>  3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb 
> b/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
> index 17ae94066c..b3e9fbae62 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
> @@ -11,7 +11,7 @@ python () {
>  raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
> linux-yocto-rt to enable it")
>  }
>
> -SRCREV_machine ?= "359292dcf3fc078090666dc327d233695310"
> +SRCREV_machine ?= "bc8af638c00f28a46e77e34056079087638f6e65"
>  SRCREV_meta ?= "350b544d077955b599b54ab364f6227d96a90455"
>
>  SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb 
> b/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
> index c18278ad79..466b7063b4 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
> @@ -14,7 +14,7 @@ DEPENDS += "openssl-native util-linux-native"
>  KMETA = "kernel-meta"
>  KCONF_BSP_AUDIT_LEVEL = "2"
>
> -SRCREV_machine ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> +SRCREV_machine ?= "65a9a22786a6710fc7b4edb7cfae80dd83f591f1"
>  SRCREV_meta ?= "350b544d077955b599b54ab364f6227d96a90455"
>
>  PV = "${LINUX_VERSION}+git${SRCPV}"
> diff --git a/meta/recipes-kernel/linux/linux-yocto_5.19.bb 
> b/meta/recipes-kernel/linux/linux-yocto_5.19.bb
> index 4fc1ae9245..f882972e35 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_5.19.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_5.19.bb
> @@ -13,16 +13,16 @@ KBRANCH:qemux86  ?= "v5.19/standard/base"
>  KBRANCH:qemux86-64 ?= "v5.19/standard/base"
>  KBRANCH:qemumips64 ?= "v5.19/standard/mti-malta64"
>
> -SRCREV_machine:qemuarm ?= "9111e441d26961e67bef7866919c51b27e794bac"
> -SRCREV_machine:qemuarm64 ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> -SRCREV_machine:qemumips ?= "5f89b6548b6665f3ebec11266f2c7db2793129da"
> -SRCREV_machine:qemuppc ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> -SRCREV_machine:qemuriscv64 ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> -SRCREV_machine:qemuriscv32 ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> -SRCREV_machine:qemux86 ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> -SRCREV_machine:qemux86-64 ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> -SRCREV_machine:qemumips64 ?= "99613988297ac45653cc81319e63b2821645a3ba"
> -SRCREV_machine ?= "44a446e91acea4f2f0d35896763224c3b52a3ed5"
> +SRCREV_machine:qemuarm ?= "446661f6a3b07535304497c1a51d9cab95f48f0b"
> +SRCREV_machine:qemuarm64 ?= "65a9a22786a6710fc7b4edb7cfae80dd83f591f1"
> +SRCREV_machine:qemumips ?= "98da147618fca3da29cf1c6ab9c53f24de2c587c"
> +SRCREV_machine:qemuppc ?= "65a9a22786a6710fc7b4edb7cfae80dd83f591f1"
> +SRCREV_machine:qemuriscv64 ?= "65a9a22786a6710fc7b4edb7cfae80dd83f591f1"
> +SRCREV_machine:qemuriscv32 ?= "65a9a22786a6710fc7b4edb7cfae80dd83f591f1"
> +SRCREV_machine:qemux86 ?= "65a9a22786a6710fc7b4edb7cfae80dd83f591f1"
> +SRCREV_machine:qemux86-64 ?= "65a9a22786a6710fc7b4edb7cfae80dd83f591f1"
> +SRCREV_machine:qemumips64 ?= "53842054198d851b5deb5810afaf126156efbb54"
> +SRCREV_machine ?= "65a9a22786a6710fc7b4edb7cfae80dd83f591f1"
>  SRCREV_meta ?= "350b544d077955b599b54ab364f6227d96a90455"
>
>  # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
> you'll
> --
> 2.19.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171125): 
https://lists.openembedded.org/g/openembedded-core/message/171125
Mute This Topic: https://lists.openembedded.org/mt/93957254/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] lttng-tools: Disable on qemuriscv32

[Khem Raj]

On 9/26/22 1:08 AM, He Zhe wrote:

lttng-tools requires SYS_ppoll and SYS_pselect6 which are not supported on
riscv32. This has been confirmed by lttng-tools upstream.
https://github.com/lttng/lttng-tools/pull/162

It's also turned off for riscv32 in meta-riscv.
https://github.com/riscv/meta-riscv/blob/master/conf/layer.conf

Signed-off-by: He Zhe 
---
  meta/recipes-kernel/lttng/lttng-platforms.inc | 4 
  1 file changed, 4 insertions(+)

diff --git a/meta/recipes-kernel/lttng/lttng-platforms.inc 
b/meta/recipes-kernel/lttng/lttng-platforms.inc
index 933c65d85d..98b13b194c 100644
--- a/meta/recipes-kernel/lttng/lttng-platforms.inc
+++ b/meta/recipes-kernel/lttng/lttng-platforms.inc
@@ -15,3 +15,7 @@ LTTNGUST:arc = ""
  
  COMPATIBLE_HOST:arc:pn-lttng-ust = "null"
  
+# Whether the platform supports lttng-tools

+# lttng-tools requires SYS_ppoll and SYS_pselect6 which are not supported on 
riscv32.
+# It's also turned off for riscv32 in meta-riscv. See 
https://github.com/riscv/meta-riscv/blob/master/conf/layer.conf
+COMPATIBLE_HOST:qemuriscv32:pn-lttng-tools = "null"



Its perhaps better to disable it rv32 wide not just form qemu.








OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171069): 
https://lists.openembedded.org/g/openembedded-core/message/171069
Mute This Topic: https://lists.openembedded.org/mt/93922533/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 1/2] iproute2: Unset CLEANBROKEN

[Khem Raj]

On Sun, Sep 25, 2022 at 7:35 AM Changhyeok Bae 
wrote:

> Signed-off-by: Changhyeok Bae 
> ---
>  meta/recipes-connectivity/iproute2/iproute2.inc | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/meta/recipes-connectivity/iproute2/iproute2.inc
> b/meta/recipes-connectivity/iproute2/iproute2.inc
> index b1bcc1434c..c292b95e36 100644
> --- a/meta/recipes-connectivity/iproute2/iproute2.inc
> +++ b/meta/recipes-connectivity/iproute2/iproute2.inc
> @@ -13,8 +13,6 @@ DEPENDS = "flex-native bison-native iptables libcap"
>
>  inherit update-alternatives bash-completion pkgconfig
>
> -CLEANBROKEN = "1"
> -


A bit of history how it is fixed would be helpful

>
>  PACKAGECONFIG ??= "tipc elf devlink"
>  PACKAGECONFIG[tipc] = ",,libmnl,"
>  PACKAGECONFIG[elf] = ",,elfutils,"
> --
> 2.17.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171013): 
https://lists.openembedded.org/g/openembedded-core/message/171013
Mute This Topic: https://lists.openembedded.org/mt/93907752/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] [PULL] [PATCH 1/1] openssh: Install header + lib files

[Khem Raj]

Yes it is and I think you
Might need to subscribe to it

On Fri, Sep 23, 2022 at 1:51 PM Willy Tu  wrote:

> ok, sounds good. Thanks.
>
> I'll take a closer look at it to update it.
>
> On a related note, is `openembedded-core@lists.openembedded.org` the
> right email? It is giving me errors when trying to send to that
> address.
>
> Willy Tu
>
> On Fri, Sep 23, 2022 at 10:48 AM Khem Raj  wrote:
> >
> >
> >
> > On Fri, Sep 23, 2022 at 12:56 PM Willy Tu  wrote:
> >>
> >> friendly ping (again), but this time with plain text only.
> >
> >
> > I think it should be done with packageconfig which is at recipe scope
> and then in your own distro you could enable it via bbappend or via other
> global knob if you wish so
> >
> > Secondly lot of these seems to be something that devel package should
> have already can you check that and ensure we are not double installing the
> files
> >
> >>
> >> Willy Tu
> >>
> >>
> >> On Thu, Sep 1, 2022 at 5:16 PM Willy Tu  wrote:
> >> >
> >> > Instal API only if opensshinternals is in DISTRO_FEATURES.
> >> >
> >> > Install the OpenSSH header + lib files for other repo to build using
> it.
> >> > For example, https://github.com/google/hiba is dependent on those
> files
> >> > to build and this change is needed to meet that requirement.
> >> >
> >> > https://github.com/openembedded/meta-openembedded/pull/597
> >> >
> >> > Signed-off-by: Willy Tu 
> >> > ---
> >> >  meta/recipes-connectivity/openssh/openssh_9.0p1.bb | 11 +++
> >> >  1 file changed, 11 insertions(+)
> >> >
> >> > diff --git a/meta/recipes-connectivity/openssh/openssh_9.0p1.bb
> b/meta/recipes-connectivity/openssh/openssh_9.0p1.bb
> >> > index b63ea2b137..84da118ca6 100644
> >> > --- a/meta/recipes-connectivity/openssh/openssh_9.0p1.bb
> >> > +++ b/meta/recipes-connectivity/openssh/openssh_9.0p1.bb
> >> > @@ -137,6 +137,17 @@ do_install:append () {
> >> > ${D}${sysconfdir}/init.d/sshd
> >> >
> >> > install -D -m 0755 ${WORKDIR}/sshd_check_keys
> ${D}${libexecdir}/${BPN}/sshd_check_keys
> >> > +
> >> > +   if ${@bb.utils.contains('DISTRO_FEATURES',
> 'opensshinternals', 'true', 'false', d)}; then
> >> > +   install -d ${D}${includedir}/ssh
> >> > +   install -d ${D}${includedir}/ssh/openbsd-compat
> >> > +   install -m0644 ${S}/*.h ${D}${includedir}/ssh
> >> > +   install -m0644 ${S}/openbsd-compat/*.h
> ${D}${includedir}/ssh/openbsd-compat
> >> > +
> >> > +   install -d ${D}${libdir}
> >> > +   install -m0644 ${S}/libssh.a ${D}${libdir}
> >> > +   install -m0644
> ${S}/openbsd-compat/libopenbsd-compat.a ${D}${libdir}
> >> > +   fi
> >> >  }
> >> >
> >> >  do_install_ptest () {
> >> > --
> >> > 2.37.2.789.g6183377224-goog
> >> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171003): 
https://lists.openembedded.org/g/openembedded-core/message/171003
Mute This Topic: https://lists.openembedded.org/mt/93875964/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] [PULL] [PATCH 1/1] openssh: Install header + lib files

[Khem Raj]

On Fri, Sep 23, 2022 at 12:56 PM Willy Tu  wrote:

> friendly ping (again), but this time with plain text only.
>

I think it should be done with packageconfig which is at recipe scope and
then in your own distro you could enable it via bbappend or via other
global knob if you wish so

Secondly lot of these seems to be something that devel package should have
already can you check that and ensure we are not double installing the
files


> Willy Tu
>
>
> On Thu, Sep 1, 2022 at 5:16 PM Willy Tu  wrote:
> >
> > Instal API only if opensshinternals is in DISTRO_FEATURES.
> >
> > Install the OpenSSH header + lib files for other repo to build using it.
> > For example, https://github.com/google/hiba is dependent on those files
> > to build and this change is needed to meet that requirement.
> >
> > https://github.com/openembedded/meta-openembedded/pull/597
> >
> > Signed-off-by: Willy Tu 
> > ---
> >  meta/recipes-connectivity/openssh/openssh_9.0p1.bb | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/meta/recipes-connectivity/openssh/openssh_9.0p1.bb
> b/meta/recipes-connectivity/openssh/openssh_9.0p1.bb
> > index b63ea2b137..84da118ca6 100644
> > --- a/meta/recipes-connectivity/openssh/openssh_9.0p1.bb
> > +++ b/meta/recipes-connectivity/openssh/openssh_9.0p1.bb
> > @@ -137,6 +137,17 @@ do_install:append () {
> > ${D}${sysconfdir}/init.d/sshd
> >
> > install -D -m 0755 ${WORKDIR}/sshd_check_keys
> ${D}${libexecdir}/${BPN}/sshd_check_keys
> > +
> > +   if ${@bb.utils.contains('DISTRO_FEATURES', 'opensshinternals',
> 'true', 'false', d)}; then
> > +   install -d ${D}${includedir}/ssh
> > +   install -d ${D}${includedir}/ssh/openbsd-compat
> > +   install -m0644 ${S}/*.h ${D}${includedir}/ssh
> > +   install -m0644 ${S}/openbsd-compat/*.h
> ${D}${includedir}/ssh/openbsd-compat
> > +
> > +   install -d ${D}${libdir}
> > +   install -m0644 ${S}/libssh.a ${D}${libdir}
> > +   install -m0644 ${S}/openbsd-compat/libopenbsd-compat.a
> ${D}${libdir}
> > +   fi
> >  }
> >
> >  do_install_ptest () {
> > --
> > 2.37.2.789.g6183377224-goog
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171002): 
https://lists.openembedded.org/g/openembedded-core/message/171002
Mute This Topic: https://lists.openembedded.org/mt/93875964/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 v2] gcompat: Add __getauxval wrapper needed on aarch64

[Khem Raj]

On Wed, Sep 21, 2022 at 9:38 AM Richard Purdie
 wrote:
>
> On Tue, 2022-09-20 at 19:23 -0700, Khem Raj wrote:
> > Update SRCREV to bring in few bug fixes
> > Install a .so symlink which could be used during linking
> >
> > Signed-off-by: Khem Raj 
> > ---
> > v2: Symlink should point to base_libdir not libdir
>
> It still breaks:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/5884/steps/11/logs/stdio
>

yeah patches in conference benched do not help :) I realised that we
have to create libdir
since it may not always be created. Have this time built with poky
distro locally on qemux86
please try v3.

> Cheers,
>
> Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170963): 
https://lists.openembedded.org/g/openembedded-core/message/170963
Mute This Topic: https://lists.openembedded.org/mt/93819185/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 v3] gcompat: Add __getauxval wrapper needed on aarch64

[Khem Raj]

Update SRCREV to bring in few bug fixes
Install a .so symlink which could be used during linking

install libdir to create if not existing

Signed-off-by: Khem Raj 
---
v2: Symlink should point to base_libdir not libdir
v3: Create libdir as it might not be created always

 .../musl/gcompat/0001-auxv-new-module.patch   | 59 +++
 meta/recipes-core/musl/gcompat_git.bb |  7 ++-
 2 files changed, 64 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch

diff --git a/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch 
b/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch
new file mode 100644
index 00..ee292f3841
--- /dev/null
+++ b/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch
@@ -0,0 +1,59 @@
+From aecd42801904462501a890d173648e4e826eda19 Mon Sep 17 00:00:00 2001
+From: "A. Wilcox" 
+Date: Sat, 23 Oct 2021 23:29:40 -0500
+Subject: [PATCH] auxv: new module
+
+Adds `__getauxval` wrapper, needed for Parallels Tools GUI installer.
+
+Upstream-Status: Submitted 
[https://git.adelielinux.org/adelie/gcompat/-/commit/e860a38a88c7ea148ee15976136a1f83ea13f8e0]
+Signed-off-by: Khem Raj 
+---
+ CHANGELOG.rst | 5 +
+ Makefile  | 1 +
+ libgcompat/auxv.c | 6 ++
+ 3 files changed, 12 insertions(+)
+ create mode 100644 libgcompat/auxv.c
+
+diff --git a/CHANGELOG.rst b/CHANGELOG.rst
+index ce6859b..c3a9cee 100644
+--- a/CHANGELOG.rst
 b/CHANGELOG.rst
+@@ -11,6 +11,11 @@
+ 1.1 (202?-??-??)
+ 
+ 
++auxv
++
++
++* Add __getauxval wrapper for getauxval.
++
+ locale
+ --
+ 
+diff --git a/Makefile b/Makefile
+index cbb7634..1893cc1 100644
+--- a/Makefile
 b/Makefile
+@@ -2,6 +2,7 @@ LIBGCOMPAT_INCLUDE = \
+   libgcompat/alias.h \
+   libgcompat/internal.h
+ LIBGCOMPAT_SRC = \
++  libgcompat/auxv.c   \
+   libgcompat/ctype.c  \
+   libgcompat/cxx_thread.c \
+   libgcompat/dlfcn.c  \
+diff --git a/libgcompat/auxv.c b/libgcompat/auxv.c
+new file mode 100644
+index 000..01de376
+--- /dev/null
 b/libgcompat/auxv.c
+@@ -0,0 +1,6 @@
++#include  /* getauxval */
++
++unsigned long __getauxval(unsigned long value)
++{
++  return getauxval(value);
++}
+-- 
+2.37.3
+
diff --git a/meta/recipes-core/musl/gcompat_git.bb 
b/meta/recipes-core/musl/gcompat_git.bb
index b051e43b6c..11f3c58769 100644
--- a/meta/recipes-core/musl/gcompat_git.bb
+++ b/meta/recipes-core/musl/gcompat_git.bb
@@ -8,12 +8,13 @@ LICENSE = "NCSA"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=eb33ef4af05a9c7602843afb7adfe792"
 
 SRC_URI = 
"git://git.adelielinux.org/adelie/gcompat.git;protocol=https;branch=current \
-  "
+   file://0001-auxv-new-module.patch \
+   "
 SRC_URI:append:powerpc = "\
file://0001-make-Static-PIE-does-not-work-on-musl-ppc.patch \
"
 PV = "1.0.0+1.1+git${SRCPV}"
-SRCREV = "4d6a5156a6eb7f56b30d93853a872e36dadde81b"
+SRCREV = "c6921a1aa454bb87671f9bd1ecfe47d80d1620aa"
 
 S = "${WORKDIR}/git"
 
@@ -42,6 +43,8 @@ do_install () {
install -d ${D}${nonarch_base_libdir}${SITEINFO_BITS}
ln -rs ${D}${GLIBC_LDSO} 
${D}${nonarch_base_libdir}${SITEINFO_BITS}/`basename ${GLIBC_LDSO}`
fi
+   install -d ${D}${libdir}
+   ln -sf ${base_libdir}/libgcompat.so.0 ${D}${libdir}/libgcompat.so
 }
 
 FILES:${PN} += "${nonarch_base_libdir}${SITEINFO_BITS}"
-- 
2.37.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170962): 
https://lists.openembedded.org/g/openembedded-core/message/170962
Mute This Topic: https://lists.openembedded.org/mt/93839392/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: only apply patch to fix ALWAYS_INLINE for native

[Khem Raj]

On Wed, Sep 21, 2022 at 1:31 AM kai  wrote:

> From: Kai Kang 
>
> 0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch is not
> required by target mesa any more. But it still fails to compile
> mesa-native with DEBUG_BUILD enabled on Ubuntu 18.04 with gcc 7.5.0
> without this patch:


Perhaps add a comment on the recipe as well so we do not forget to remove
it when Ubuntu 18.04 is dropped in future

>
>
> | ../mesa-22.1.6/src/compiler/nir/nir_inline_helpers.h: In function
> ‘nir_opt_move_block’:
> | ../mesa-22.1.6/src/compiler/nir/nir_opt_move.c:55:1: error: inlining
> failed in call to
> always_inline ‘src_is_ssa’: indirect function call with a yet
> undetermined callee
> |  src_is_ssa(nir_src *src, void *state)
> |  ^~
>
> So only apply it for mesa-native.
>
> Signed-off-by: Kai Kang 
> ---
>  meta/recipes-graphics/mesa/mesa.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index ea7ed4fd27..c306c6b726 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -22,8 +22,8 @@ SRC_URI = "
> https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
> file://0001-util-format-Check-for-NEON-before-using-it.patch \
>
> file://0001-Revert-egl-wayland-deprecate-drm_handle_format-and-d.patch \
>
> file://0001-swrast_kms-use-swkmsDRI2Extension-instead-of-driDRI2.patch \
> -
>  file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch \
> "
> +SRC_URI:append:class-native = "
> file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch"
>
>  SRC_URI[sha256sum] =
> "22ced061eb9adab8ea35368246c1995c09723f3f71653cd5050c5cec376e671a"
>
> --
> 2.17.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170933): 
https://lists.openembedded.org/g/openembedded-core/message/170933
Mute This Topic: https://lists.openembedded.org/mt/93820842/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] gcompat: Add __getauxval wrapper needed on aarch64

[Khem Raj]

On 9/20/22 5:39 AM, Richard Purdie wrote:

On Sat, 2022-09-17 at 14:13 -0700, Khem Raj wrote:

Update SRCREV to bring in few bug fixes
Install a .so symlink which could be used during linking

Signed-off-by: Khem Raj 
---
  .../musl/gcompat/0001-auxv-new-module.patch   | 59 +++
  meta/recipes-core/musl/gcompat_git.bb |  6 +-
  2 files changed, 63 insertions(+), 2 deletions(-)
  create mode 100644 meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch


https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/5873
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/5890



Yeah my bad, Yoe distro uses usrmerge feature, and I forgot the main 
library is installed in base_libdir and not libdir, sent a v2 with this 
changed



Cheers,

Richard


OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170918): 
https://lists.openembedded.org/g/openembedded-core/message/170918
Mute This Topic: https://lists.openembedded.org/mt/93751127/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 v2] gcompat: Add __getauxval wrapper needed on aarch64

[Khem Raj]

Update SRCREV to bring in few bug fixes
Install a .so symlink which could be used during linking

Signed-off-by: Khem Raj 
---
v2: Symlink should point to base_libdir not libdir

 .../musl/gcompat/0001-auxv-new-module.patch   | 59 +++
 meta/recipes-core/musl/gcompat_git.bb |  6 +-
 2 files changed, 63 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch

diff --git a/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch 
b/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch
new file mode 100644
index 00..ee292f3841
--- /dev/null
+++ b/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch
@@ -0,0 +1,59 @@
+From aecd42801904462501a890d173648e4e826eda19 Mon Sep 17 00:00:00 2001
+From: "A. Wilcox" 
+Date: Sat, 23 Oct 2021 23:29:40 -0500
+Subject: [PATCH] auxv: new module
+
+Adds `__getauxval` wrapper, needed for Parallels Tools GUI installer.
+
+Upstream-Status: Submitted 
[https://git.adelielinux.org/adelie/gcompat/-/commit/e860a38a88c7ea148ee15976136a1f83ea13f8e0]
+Signed-off-by: Khem Raj 
+---
+ CHANGELOG.rst | 5 +
+ Makefile  | 1 +
+ libgcompat/auxv.c | 6 ++
+ 3 files changed, 12 insertions(+)
+ create mode 100644 libgcompat/auxv.c
+
+diff --git a/CHANGELOG.rst b/CHANGELOG.rst
+index ce6859b..c3a9cee 100644
+--- a/CHANGELOG.rst
 b/CHANGELOG.rst
+@@ -11,6 +11,11 @@
+ 1.1 (202?-??-??)
+ 
+ 
++auxv
++
++
++* Add __getauxval wrapper for getauxval.
++
+ locale
+ --
+ 
+diff --git a/Makefile b/Makefile
+index cbb7634..1893cc1 100644
+--- a/Makefile
 b/Makefile
+@@ -2,6 +2,7 @@ LIBGCOMPAT_INCLUDE = \
+   libgcompat/alias.h \
+   libgcompat/internal.h
+ LIBGCOMPAT_SRC = \
++  libgcompat/auxv.c   \
+   libgcompat/ctype.c  \
+   libgcompat/cxx_thread.c \
+   libgcompat/dlfcn.c  \
+diff --git a/libgcompat/auxv.c b/libgcompat/auxv.c
+new file mode 100644
+index 000..01de376
+--- /dev/null
 b/libgcompat/auxv.c
+@@ -0,0 +1,6 @@
++#include  /* getauxval */
++
++unsigned long __getauxval(unsigned long value)
++{
++  return getauxval(value);
++}
+-- 
+2.37.3
+
diff --git a/meta/recipes-core/musl/gcompat_git.bb 
b/meta/recipes-core/musl/gcompat_git.bb
index b051e43b6c..773263809b 100644
--- a/meta/recipes-core/musl/gcompat_git.bb
+++ b/meta/recipes-core/musl/gcompat_git.bb
@@ -8,12 +8,13 @@ LICENSE = "NCSA"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=eb33ef4af05a9c7602843afb7adfe792"
 
 SRC_URI = 
"git://git.adelielinux.org/adelie/gcompat.git;protocol=https;branch=current \
-  "
+   file://0001-auxv-new-module.patch \
+   "
 SRC_URI:append:powerpc = "\
file://0001-make-Static-PIE-does-not-work-on-musl-ppc.patch \
"
 PV = "1.0.0+1.1+git${SRCPV}"
-SRCREV = "4d6a5156a6eb7f56b30d93853a872e36dadde81b"
+SRCREV = "c6921a1aa454bb87671f9bd1ecfe47d80d1620aa"
 
 S = "${WORKDIR}/git"
 
@@ -42,6 +43,7 @@ do_install () {
install -d ${D}${nonarch_base_libdir}${SITEINFO_BITS}
ln -rs ${D}${GLIBC_LDSO} 
${D}${nonarch_base_libdir}${SITEINFO_BITS}/`basename ${GLIBC_LDSO}`
fi
+   ln -sf ${base_libdir}/libgcompat.so.0 ${D}${libdir}/libgcompat.so
 }
 
 FILES:${PN} += "${nonarch_base_libdir}${SITEINFO_BITS}"
-- 
2.37.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170917): 
https://lists.openembedded.org/g/openembedded-core/message/170917
Mute This Topic: https://lists.openembedded.org/mt/93819185/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 0/9] kernel-yocto: consolidated pull request

[Khem Raj]

On Mon, Sep 19, 2022 at 10:28 AM Bruce Ashfield
 wrote:
>
> From: Bruce Ashfield 
>
> Richard,
>
> Here's the next set of -stable updates to the active reference kernels.
> I also have updates back to 5.4 that I'll send to the various stable
> branches shortly.
>
> I also have a couple of kern-tools fixes. One to solve a problem reported
> on the list about some directory structures (typically created from KAS)
> to break the meta-data phase of the kernel build. I've fixed that issue,
> then fixed the other regressions that fix caused, and have everything
> passing sanity. There shouldn't be any fallout, but I'll be keeping a
> close eye on things.
>
> I also have Khem's MDIO configuration change in the queue, along with
> a previously hidden kern-tools feature that allows it to not warn if
> something is 'enabled' (y or m).

Cool. Thanks for keeping this in. I am not able to do much this week
due to travel, but I will try to test it out nevertheless.

>
> Cheers,
>
> Bruce
>
> The following changes since commit fa86bfd3617b54dbf7e44093ae0e6f35538bdabc:
>
>   diffoscope: upgrade 220 -> 221 (2022-09-17 07:47:08 +0100)
>
> are available in the Git repository at:
>
>   git://git.yoctoproject.org/poky-contrib zedd/kernel
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel
>
> Bruce Ashfield (8):
>   linux-yocto/5.15: update to v5.15.63
>   linux-yocto/5.19: update to v5.19.5
>   linux-yocto/5.19: update to v5.19.7
>   linux-yocto/5.15: update to v5.15.65
>   kern-tools: fix queue processing in relative TOPDIR configurations
>   kern-tools: allow 'y' or 'm' to avoid config audit warnings
>   linux-yocto/5.19: update to v5.19.9
>   linux-yocto/5.15: update to v5.15.68
>
> Khem Raj (1):
>   linux-yocto: Enable mdio for qemu
>
>  .../kern-tools/kern-tools-native_git.bb   |  2 +-
>  .../linux/linux-yocto-rt_5.15.bb  |  6 ++--
>  .../linux/linux-yocto-rt_5.19.bb  |  6 ++--
>  .../linux/linux-yocto-tiny_5.15.bb|  6 ++--
>  .../linux/linux-yocto-tiny_5.19.bb|  6 ++--
>  meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 -
>  meta/recipes-kernel/linux/linux-yocto_5.19.bb | 28 +--
>  7 files changed, 40 insertions(+), 40 deletions(-)
>
> --
> 2.19.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170882): 
https://lists.openembedded.org/g/openembedded-core/message/170882
Mute This Topic: https://lists.openembedded.org/mt/93782003/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] gcompat: Add __getauxval wrapper needed on aarch64

[Khem Raj]

Update SRCREV to bring in few bug fixes
Install a .so symlink which could be used during linking

Signed-off-by: Khem Raj 
---
 .../musl/gcompat/0001-auxv-new-module.patch   | 59 +++
 meta/recipes-core/musl/gcompat_git.bb |  6 +-
 2 files changed, 63 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch

diff --git a/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch 
b/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch
new file mode 100644
index 00..ee292f3841
--- /dev/null
+++ b/meta/recipes-core/musl/gcompat/0001-auxv-new-module.patch
@@ -0,0 +1,59 @@
+From aecd42801904462501a890d173648e4e826eda19 Mon Sep 17 00:00:00 2001
+From: "A. Wilcox" 
+Date: Sat, 23 Oct 2021 23:29:40 -0500
+Subject: [PATCH] auxv: new module
+
+Adds `__getauxval` wrapper, needed for Parallels Tools GUI installer.
+
+Upstream-Status: Submitted 
[https://git.adelielinux.org/adelie/gcompat/-/commit/e860a38a88c7ea148ee15976136a1f83ea13f8e0]
+Signed-off-by: Khem Raj 
+---
+ CHANGELOG.rst | 5 +
+ Makefile  | 1 +
+ libgcompat/auxv.c | 6 ++
+ 3 files changed, 12 insertions(+)
+ create mode 100644 libgcompat/auxv.c
+
+diff --git a/CHANGELOG.rst b/CHANGELOG.rst
+index ce6859b..c3a9cee 100644
+--- a/CHANGELOG.rst
 b/CHANGELOG.rst
+@@ -11,6 +11,11 @@
+ 1.1 (202?-??-??)
+ 
+ 
++auxv
++
++
++* Add __getauxval wrapper for getauxval.
++
+ locale
+ --
+ 
+diff --git a/Makefile b/Makefile
+index cbb7634..1893cc1 100644
+--- a/Makefile
 b/Makefile
+@@ -2,6 +2,7 @@ LIBGCOMPAT_INCLUDE = \
+   libgcompat/alias.h \
+   libgcompat/internal.h
+ LIBGCOMPAT_SRC = \
++  libgcompat/auxv.c   \
+   libgcompat/ctype.c  \
+   libgcompat/cxx_thread.c \
+   libgcompat/dlfcn.c  \
+diff --git a/libgcompat/auxv.c b/libgcompat/auxv.c
+new file mode 100644
+index 000..01de376
+--- /dev/null
 b/libgcompat/auxv.c
+@@ -0,0 +1,6 @@
++#include  /* getauxval */
++
++unsigned long __getauxval(unsigned long value)
++{
++  return getauxval(value);
++}
+-- 
+2.37.3
+
diff --git a/meta/recipes-core/musl/gcompat_git.bb 
b/meta/recipes-core/musl/gcompat_git.bb
index b051e43b6c..ffdb11a190 100644
--- a/meta/recipes-core/musl/gcompat_git.bb
+++ b/meta/recipes-core/musl/gcompat_git.bb
@@ -8,12 +8,13 @@ LICENSE = "NCSA"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=eb33ef4af05a9c7602843afb7adfe792"
 
 SRC_URI = 
"git://git.adelielinux.org/adelie/gcompat.git;protocol=https;branch=current \
-  "
+   file://0001-auxv-new-module.patch \
+   "
 SRC_URI:append:powerpc = "\
file://0001-make-Static-PIE-does-not-work-on-musl-ppc.patch \
"
 PV = "1.0.0+1.1+git${SRCPV}"
-SRCREV = "4d6a5156a6eb7f56b30d93853a872e36dadde81b"
+SRCREV = "c6921a1aa454bb87671f9bd1ecfe47d80d1620aa"
 
 S = "${WORKDIR}/git"
 
@@ -42,6 +43,7 @@ do_install () {
install -d ${D}${nonarch_base_libdir}${SITEINFO_BITS}
ln -rs ${D}${GLIBC_LDSO} 
${D}${nonarch_base_libdir}${SITEINFO_BITS}/`basename ${GLIBC_LDSO}`
fi
+ln -sf libgcompat.so.0 ${D}${libdir}/libgcompat.so
 }
 
 FILES:${PN} += "${nonarch_base_libdir}${SITEINFO_BITS}"
-- 
2.37.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170841): 
https://lists.openembedded.org/g/openembedded-core/message/170841
Mute This Topic: https://lists.openembedded.org/mt/93751127/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] [RFC][PATCH 0/1] mesa: clover | Microsoft/Intel CLC: fix building OpenCL programs

[Khem Raj]

On Sat, Sep 17, 2022 at 4:56 AM Andrey Konovalov
 wrote:
>
> This fixes the errors like:
>
> -8<-
> dragonboard-845c:~$ clinfo
> 
>Max work group size 1024
> === CL_PROGRAM_BUILD_LOG ===
> :1:10: fatal error: 'opencl-c.h' file not found
>Preferred work group size multiple (kernel)  ker>
>Preferred / native vector sizes
>  char16 / 16
> 
> -8<-
>
> Here clinfo runs on target board and produces correct output except for
> the "Preferred work group size multiple (kernel)" item. This is the only
> item which requires clinfo to build and run a small OpenCL kernel. But
> building OpenCL program fails as clover can't find the include file.
>
> The reason is that the include search path is set at mesa build time by
> setting CLANG_RESOURCE_DIR to "$(llvm-config --libdir)something" and
> passing it in cpp args. This results in path to sysroot included into
> CLANG_RESOURCE_DIR:
>
> -8<-
> dragonboard-845c:~$ strace clinfo 2>&1|grep include
> newfstatat(AT_FDCWD, 
> "/workdir/master.test/build-rpb/tmp-rpb-glibc/work/armv8-2>
> newfstatat(AT_FDCWD, "/usr/local/include", 0xfc3bad68, 0) = -1 ENOENT (No 
> s>
> newfstatat(AT_FDCWD, 
> "/workdir/master.test/build-rpb/tmp-rpb-glibc/work/armv8-2>
> newfstatat(AT_FDCWD, "/usr/include", {st_mode=S_IFDIR|0755, st_size=12288, 
> ...}>
> openat(AT_FDCWD, "/usr/include/opencl-c.h", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
> (No>
> -8<-
>
> Hence clover fails to locate /usr/lib/clang/14.0.6/include/opencl-c.h.
>
> Microsoft/Intel CLC *should* have the same problem, as the code in
> compiler/clc/clc_helpers.cpp is pretty close to the one in
> gallium/frontends/clover/llvm/invocation.cpp. Except for the case when
> the contents of opencl-c.h is compiled into the CLC library (seems to be
> the most common configuration for Windows), and the problem with locating
> the include file on the target fs doesn't exist.
>
> This patch is RFC for two reasons:
> * I am not sure if using hardcoded "/usr/lib" is good enough
> * The compiler/clc/clc_helpers.cpp part is not tested. Maybe splitting
>   the patch into two - the clover and the Microsoft/Intel CLC parts separated 
> -
>   would make more sense.
>
> Last note for those to try reproducing the build with clover:
> clover uses libclc from meta-clang. meta-clang master branch has moved to
> clang 15.0.0 recently, which breaks mesa build as the mesa fixes to account
> for clang 15.0.0 changes have been merged into mesa main branch, but have not
> yet made it into the last mesa release.
> My temporary solution is rolling meta-clang back to the commit just before the
> 14.0.6 -> 15.0.0 update, and cherry-picking "llvm-config: Replace TARGET_*
> flags with normal equivalent flags". The latter is not required in my case,
> it just makes llvm-config wrapper from meta-clang (the one used in this build)
> to look closer to the llvm-config wrapper from oe-core.
>
> Andrey Konovalov (1):
>   mesa: fix building OpenCL programs
>
>  ...-meson.CLANG_RESOURCE_DIR-workaround.patch | 42 +++
>  meta/recipes-graphics/mesa/mesa.inc   |  1 +
>  2 files changed, 43 insertions(+)
>  create mode 100644 
> meta/recipes-graphics/mesa/files/0001-meson.CLANG_RESOURCE_DIR-workaround.patch
>

I am not able to find the patch with above changes. Did you miss sending it ?


> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170840): 
https://lists.openembedded.org/g/openembedded-core/message/170840
Mute This Topic: https://lists.openembedded.org/mt/93741464/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] apt: Fix type mismatches and ptest builds

[Khem Raj]

These issues are found with clang15

Signed-off-by: Khem Raj 
---
 ...me_t-and-suseconds_t-from-std-chrono.patch | 64 +++
 ...tive-helper-Undefine-_FORTIFY_SOURCE.patch | 27 
 meta/recipes-devtools/apt/apt_2.4.5.bb|  2 +
 3 files changed, 93 insertions(+)
 create mode 100644 
meta/recipes-devtools/apt/apt/0001-typecast-time_t-and-suseconds_t-from-std-chrono.patch
 create mode 100644 
meta/recipes-devtools/apt/apt/0002-interactive-helper-Undefine-_FORTIFY_SOURCE.patch

diff --git 
a/meta/recipes-devtools/apt/apt/0001-typecast-time_t-and-suseconds_t-from-std-chrono.patch
 
b/meta/recipes-devtools/apt/apt/0001-typecast-time_t-and-suseconds_t-from-std-chrono.patch
new file mode 100644
index 00..fc3509d336
--- /dev/null
+++ 
b/meta/recipes-devtools/apt/apt/0001-typecast-time_t-and-suseconds_t-from-std-chrono.patch
@@ -0,0 +1,64 @@
+From b7a1a4d3259557f2587f7d5d47502691d94c21c2 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Fri, 16 Sep 2022 20:00:30 -0700
+Subject: [PATCH 1/2] typecast time_t and suseconds_t from std::chrono
+
+This fixes build on some architectures like mips
+progress.cc:125:31: error: non-constant-expression cannot be narrowed from 
type 'std::chrono::duration::rep' (aka 'long long') to '__time_t' 
(aka 'long') in initializer list [-Wc++11-narrowing]
+   struct timeval NowTime = { Now_sec.count(), Now_usec.count() };
+
+Upstream-Status: Submitted 
[https://salsa.debian.org/apt-team/apt/-/merge_requests/259]
+Signed-off-by: Khem Raj 
+---
+ apt-pkg/acquire.cc   | 4 ++--
+ apt-pkg/contrib/progress.cc  | 2 +-
+ ftparchive/apt-ftparchive.cc | 2 +-
+ 3 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/apt-pkg/acquire.cc b/apt-pkg/acquire.cc
+index 100ccde..dd0624a 100644
+--- a/apt-pkg/acquire.cc
 b/apt-pkg/acquire.cc
+@@ -53,11 +53,11 @@
+ using namespace std;
+ 
+ // helper to convert time_point to a timeval
+-static struct timeval 
SteadyDurationToTimeVal(std::chrono::steady_clock::duration Time)
++constexpr struct timeval 
SteadyDurationToTimeVal(std::chrono::steady_clock::duration Time)
+ {
+auto const Time_sec = 
std::chrono::duration_cast(Time);
+auto const Time_usec = 
std::chrono::duration_cast(Time - Time_sec);
+-   return {Time_sec.count(), Time_usec.count()};
++   return timeval{static_cast(Time_sec.count()), 
static_cast(Time_usec.count())};
+ }
+ 
+ std::string pkgAcquire::URIEncode(std::string const )/*{{{*/
+diff --git a/apt-pkg/contrib/progress.cc b/apt-pkg/contrib/progress.cc
+index 03f88d4..eb688b9 100644
+--- a/apt-pkg/contrib/progress.cc
 b/apt-pkg/contrib/progress.cc
+@@ -122,7 +122,7 @@ bool OpProgress::CheckChange(float Interval)
+auto const Now = std::chrono::steady_clock::now().time_since_epoch();
+auto const Now_sec = std::chrono::duration_cast(Now);
+auto const Now_usec = 
std::chrono::duration_cast(Now - Now_sec);
+-   struct timeval NowTime = { Now_sec.count(), Now_usec.count() };
++   struct timeval NowTime = { static_cast(Now_sec.count()), 
static_cast(Now_usec.count()) };
+ 
+std::chrono::duration Delta =
+   std::chrono::seconds(NowTime.tv_sec - LastTime.tv_sec) +
+diff --git a/ftparchive/apt-ftparchive.cc b/ftparchive/apt-ftparchive.cc
+index 56fdc22..0a253b1 100644
+--- a/ftparchive/apt-ftparchive.cc
 b/ftparchive/apt-ftparchive.cc
+@@ -58,7 +58,7 @@ static struct timeval GetTimevalFromSteadyClock()
/*{{{*/
+auto const Time = std::chrono::steady_clock::now().time_since_epoch();
+auto const Time_sec = 
std::chrono::duration_cast(Time);
+auto const Time_usec = 
std::chrono::duration_cast(Time - Time_sec);
+-   return { Time_sec.count(), Time_usec.count() };
++   return { static_cast(Time_sec.count()), 
static_cast(Time_usec.count()) };
+ }
+   /*}}}*/
+ static auto GetTimeDeltaSince(struct timeval StartTime)   
/*{{{*/
+-- 
+2.37.3
+
diff --git 
a/meta/recipes-devtools/apt/apt/0002-interactive-helper-Undefine-_FORTIFY_SOURCE.patch
 
b/meta/recipes-devtools/apt/apt/0002-interactive-helper-Undefine-_FORTIFY_SOURCE.patch
new file mode 100644
index 00..18c4641b22
--- /dev/null
+++ 
b/meta/recipes-devtools/apt/apt/0002-interactive-helper-Undefine-_FORTIFY_SOURCE.patch
@@ -0,0 +1,27 @@
+From 891076c2cf4298b5d587545497f4831f0d21caa1 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Fri, 16 Sep 2022 20:04:43 -0700
+Subject: [PATCH 2/2] interactive-helper: Undefine _FORTIFY_SOURCE
+
+This ensures that it compiles when clang compiler is passing
+-DFORTIFY_SOURCES=2
+
+Upstream-Status: Submitted 
[https://salsa.debian.org/apt-team/apt/-/merge_requests/259]
+Signed-off-by: Khem Raj 
+---
+ test/interactive-helper/libnoprofile.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/test/interactive-helper/libnoprofile.c 
b/test/interactive-helper/libnoprofile.c
+index f11b898..b26ec2a 100644
+--- a/test/interactive-helper/libnoprofile.c

[OE-core] [PATCH] grub: Apply backports to fix build with clang on x86

[Khem Raj]

Signed-off-by: Khem Raj 
---
 ...-obsoleted-malign-jumps-loops-functi.patch | 48 +++
 ...for-falign-jumps-1-beside-falign-loo.patch | 59 +++
 meta/recipes-bsp/grub/grub2.inc   |  2 +
 3 files changed, 109 insertions(+)
 create mode 100644 
meta/recipes-bsp/grub/files/0001-configure-Remove-obsoleted-malign-jumps-loops-functi.patch
 create mode 100644 
meta/recipes-bsp/grub/files/0002-configure-Check-for-falign-jumps-1-beside-falign-loo.patch

diff --git 
a/meta/recipes-bsp/grub/files/0001-configure-Remove-obsoleted-malign-jumps-loops-functi.patch
 
b/meta/recipes-bsp/grub/files/0001-configure-Remove-obsoleted-malign-jumps-loops-functi.patch
new file mode 100644
index 00..98142a7b60
--- /dev/null
+++ 
b/meta/recipes-bsp/grub/files/0001-configure-Remove-obsoleted-malign-jumps-loops-functi.patch
@@ -0,0 +1,48 @@
+From eb486898dac8cbc29b2cc39f911b657c3417ae34 Mon Sep 17 00:00:00 2001
+From: Fangrui Song via Grub-devel 
+Date: Thu, 26 Aug 2021 09:02:31 -0700
+Subject: [PATCH 1/2] configure: Remove obsoleted -malign-{jumps, loops,
+ functions}
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The GCC warns "cc1: warning: ‘-malign-loops’ is obsolete, use ‘-falign-loops’".
+The Clang silently ignores -malign-{jumps,loops,functions}.
+
+The preferred -falign-* forms have been supported since GCC 3.2. So, just
+remove -malign-{jumps,loops,functions}.
+
+Upstream-Status: Backport 
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=eb486898dac8cbc29b2cc39f911b657c3417ae34]
+Signed-off-by: Fangrui Song 
+Acked-by: Paul Menzel 
+Reviewed-by: Daniel Kiper 
+---
+ configure.ac | 9 -
+ 1 file changed, 9 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index bee28dbeb..9a12151bd 100644
+--- a/configure.ac
 b/configure.ac
+@@ -805,17 +805,8 @@ if test "x$target_cpu" = xi386; then
+   [grub_cv_cc_falign_loop=no])
+   ])
+ 
+-  AC_CACHE_CHECK([whether -malign-loops works], [grub_cv_cc_malign_loop], [
+-CFLAGS="$TARGET_CFLAGS -malign-loops=1 -Werror"
+-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
+-[grub_cv_cc_malign_loop=yes],
+-  [grub_cv_cc_malign_loop=no])
+-  ])
+-
+   if test "x$grub_cv_cc_falign_loop" = xyes; then
+ TARGET_CFLAGS="$TARGET_CFLAGS -falign-jumps=1 -falign-loops=1 
-falign-functions=1"
+-  elif test "x$grub_cv_cc_malign_loop" = xyes; then
+-TARGET_CFLAGS="$TARGET_CFLAGS -malign-jumps=1 -malign-loops=1 
-malign-functions=1"
+   fi
+ fi
+ 
+-- 
+2.37.3
+
diff --git 
a/meta/recipes-bsp/grub/files/0002-configure-Check-for-falign-jumps-1-beside-falign-loo.patch
 
b/meta/recipes-bsp/grub/files/0002-configure-Check-for-falign-jumps-1-beside-falign-loo.patch
new file mode 100644
index 00..437e5b29b2
--- /dev/null
+++ 
b/meta/recipes-bsp/grub/files/0002-configure-Check-for-falign-jumps-1-beside-falign-loo.patch
@@ -0,0 +1,59 @@
+From e372dcb0d4541ee9b9682cde088ec87a7b238ca2 Mon Sep 17 00:00:00 2001
+From: Fangrui Song via Grub-devel 
+Date: Thu, 26 Aug 2021 09:02:32 -0700
+Subject: [PATCH 2/2] configure: Check for -falign-jumps=1 beside
+ -falign-loops=1
+
+The Clang does not support -falign-jumps and only recently gained support
+for -falign-loops. The -falign-jumps=1 should be tested beside
+-fliang-loops=1 to avoid passing unrecognized options to the Clang:
+
+  clang-14: error: optimization flag '-falign-jumps=1' is not supported 
[-Werror,-Wignored-optimization-argument]
+
+The -falign-functions=1 is supported by GCC 5.1.0/Clang 3.8.0. So, just
+add the option unconditionally.
+
+Upstream-Status: Backport 
[https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e372dcb0d4541ee9b9682cde088ec87a7b238ca2]
+Signed-off-by: Fangrui Song 
+Acked-by: Paul Menzel 
+Reviewed-by: Daniel Kiper 
+---
+ configure.ac | 15 ++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 9a12151bd..eeb5d2211 100644
+--- a/configure.ac
 b/configure.ac
+@@ -798,6 +798,8 @@ fi
+ 
+ # Force no alignment to save space on i386.
+ if test "x$target_cpu" = xi386; then
++  TARGET_CFLAGS="$TARGET_CFLAGS -falign-functions=1"
++
+   AC_CACHE_CHECK([whether -falign-loops works], [grub_cv_cc_falign_loop], [
+ CFLAGS="$TARGET_CFLAGS -falign-loops=1 -Werror"
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
+@@ -806,7 +808,18 @@ if test "x$target_cpu" = xi386; then
+   ])
+ 
+   if test "x$grub_cv_cc_falign_loop" = xyes; then
+-TARGET_CFLAGS="$TARGET_CFLAGS -falign-jumps=1 -falign-loops=1 
-falign-functions=1"
++TARGET_CFLAGS="$TARGET_CFLAGS -falign-loops=1"
++  fi
++
++  AC_CACHE_CHECK([whether -falign-jumps works], [grub_cv_cc_falign_jumps], [
++CFLAGS="$TARGET_CFLAGS -falign-jumps=1 -Werror"
++AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
++[gr

Re: [OE-core] [PATCH 2/2] gcc-cross-canadian: add default plugin linker

[Khem Raj]

On Fri, Sep 16, 2022 at 12:41 AM Samuli Piippo  wrote:
>
> Fix multilib sdk issue where gcc is unable to find linker. Previous
> fix was in cdd86896c8d29135f937968e9aa07f919cf543d3 using real-ld
> symlink, but that prevented switching between bfd and gold linkers.
>
> Running compiler with debug arguments shows that collect2 tries and
> fails to find linker using the multilib triples:
>
>   $ $CC -v -Wl,-debug
>   ...
>   Looking for 'real-ld'
>   Looking for 'collect-ld'
>   Looking for 'mips-oemllib32-linux-ld'
>   Looking for 'mips-oe-linux-mips-oemllib32-linux-ld'
>   ...
>   collect2 version 12.2.0
>   ld_file_name= not found
>   ...
>   collect2: fatal error: cannot find ‘ld’
>
> Using --with-plugin-ld=ld in gcc-cross-canadian builds to set default
> linker name for collect2, lets it find the linker correctly:
>
>   Looking for 'real-ld'
>   Looking for 'collect-ld'
>   Looking for 'ld'
>   ...
>   collect2 version 12.2.0
>   ld_file_name= 
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/mips-oe-linux/gcc/mips-oe-linux/12.2.0/ld
>
> Swith between bfd and gold linker works as expected now:
>
>   $ $CC -v -Wl,-debug -fuse-ld=gold
>   ...
>   Looking for 'real-ld'
>   Looking for 'collect-ld'
>   Looking for 'ld.gold'
>   ...
>   collect2 version 12.2.0
>   ld_file_name= 
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/i686-oe-linux/gcc/i686-oe-linux/12.2.0/ld.gold
>
> Signed-off-by: Samuli Piippo 
> ---
>  meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc 
> b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
> index 38c972aa7c..c36e4cba81 100644
> --- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
> +++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
> @@ -9,6 +9,7 @@ GCCMULTILIB = "--enable-multilib"
>
>  require gcc-configure-common.inc
>
> +EXTRA_OECONF += "--with-plugin-ld=ld"

this looks fine to me. Pointing to ld is good here because then if ld
is bfd/gold/lld it always works.

>  EXTRA_OECONF_PATHS = "\
>  --with-gxx-include-dir=/not/exist${target_includedir}/c++/${BINV} \
>  
> --with-build-time-tools=${STAGING_DIR_NATIVE}${prefix_native}/${TARGET_SYS}/bin
>  \
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170796): 
https://lists.openembedded.org/g/openembedded-core/message/170796
Mute This Topic: https://lists.openembedded.org/mt/93718003/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] [kirkstone] glibc : stable 2.35 branch updates.

[Khem Raj]

On Thu, Sep 15, 2022 at 4:20 AM Sundeep KOKKONDA
 wrote:
>
> Regression test are performed and below is test summary.
>
> Test summary after glibc updates:
> 204 FAIL
> 4341 PASS
> 41 UNSUPPORTED
> 12 XFAIL
>  6 XPASS
>
> Test summary before glibc updates:
> 200 FAIL
> 4343 PASS
> 41 UNSUPPORTED
> 12 XFAIL
>  6 XPASS
>
> There are 4 tests added newly and 2 are removed with latest glibc commits.
>

which ones fail. can you describe them a bit here

>
>
> Thanks,
> Sundeep K.
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170771): 
https://lists.openembedded.org/g/openembedded-core/message/170771
Mute This Topic: https://lists.openembedded.org/mt/93697438/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] curl: Add missing perl modules in ptest rdepends

[Khem Raj]

These modules outside of perl-modules are necessary to run curl-ptests

Signed-off-by: Khem Raj 
---
 meta/recipes-support/curl/curl_7.85.0.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/curl/curl_7.85.0.bb 
b/meta/recipes-support/curl/curl_7.85.0.bb
index 3b55830415..ad6a5175bc 100644
--- a/meta/recipes-support/curl/curl_7.85.0.bb
+++ b/meta/recipes-support/curl/curl_7.85.0.bb
@@ -100,7 +100,8 @@ do_install_ptest() {
cp -rf ${D}${bindir}/curl-config ${D}${PTEST_PATH}
 }
 
-RDEPENDS:${PN}-ptest += "bash perl-modules"
+RDEPENDS:${PN}-ptest += "bash perl-modules perl-module-time-hires 
perl-module-digest-md5 \
+ perl-module-digest perl-module-ipc-open2"
 
 PACKAGES =+ "lib${BPN}"
 
-- 
2.37.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170676): 
https://lists.openembedded.org/g/openembedded-core/message/170676
Mute This Topic: https://lists.openembedded.org/mt/93690031/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] opkg: enable zstd support

[Khem Raj]

ackages, some
> > > may be quite large. E.g. one of our components produces a
> > 2.2 GB debug
> > > package (uncompressed). On large files xz requires a
> > disproportionally
> > > large amount of time resulting in 15 minutes needed to
> > simply write
> > > ipk for the abovementioned packages, whereas zstd took about
> > 45 sec.
> > > For frequent tasks like bitbaking a single package this
> > translates in
> > > a lot of saved time.
> >
> > Those are certainly compelling performance improvements.
> > Assuming that
> > the final data-segment size is within 5%-ish of xz, then I
> > would agree
> > with the rest of the thread that it should probably be the
> > contemporary
> > default.
> >
> > And if we make it the default compressor for OE IPKs, then
> > obviously my
> > criticism in the original PR is satisfied.
> >
> > > Bottom line - I think making xz a default package compressor
> > was not
> > > entirely thought through. gzip or zstd is what the default
> > should be.
> >
> > ZStandard support was only added to opkg last September [1].
> > Before
> > that, xz was the new hotness that replaced gzip. :)
> >
> > [1]
> > 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_opkg_commit_-3Fid-3D5dead419e94bce2e6b743ad786c1daec0e1aa294=DwIDaQ=ncDTmphkJTvjIDPh0hpF_4vCHvabgGkICC2epckfdiw=AhkbNonVuMIGRfPx_Qj9TsyDLWdbBqarUzFxz3aALck=VG_fgpCGq8Zgu73KQP1wTtb1D1TZftNpXj8jGnouPtGIBYyLIZbG8F-85POUcVN7=Mwoq2kkjfZhto6J5OomduJ5Rhyg_oSe-dkjeltE4Ls8=
> > 
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_opkg_commit_-3Fid-3D5dead419e94bce2e6b743ad786c1daec0e1aa294=DwIDaQ=ncDTmphkJTvjIDPh0hpF_4vCHvabgGkICC2epckfdiw=AhkbNonVuMIGRfPx_Qj9TsyDLWdbBqarUzFxz3aALck=VG_fgpCGq8Zgu73KQP1wTtb1D1TZftNpXj8jGnouPtGIBYyLIZbG8F-85POUcVN7=Mwoq2kkjfZhto6J5OomduJ5Rhyg_oSe-dkjeltE4Ls8=>
> >
> >
> > > One final note: I could not find a reasonable explanation
> > for why
> > > opkg-tools require code changes to support a different
> > compressor. BSD
> >     > tar and GNU tar both can easily accept compressors that they
> > have no
> > > idea about (via -I option) because all of them provide a
> > unified
> > > command line interface for use in pipes. If this were done
> > similar to
> > > tar, we could have used any compressor we wanted, including the
> > > multithreaded versions (zstdmt)
> >
> > Well, presumably IPK creation tools can only support the
> > matrix of
> > compression algorithms which your opkg binary can decompress.
> > I suppose
> > someone could try to implement a plugable compression module
> > system for
> > opkg. But given that nearly everyone uses opkg in an embedded
> > context,
> > I'm not sure it would get much use.
> >
> > >
> > > On Tue, Sep 13, 2022 at 12:43 PM Khem Raj
> >  wrote:
> > >
> > > On Tue, Sep 13, 2022 at 12:19 PM Alex Stewart
> > >  wrote:
> > > >
> > > > ACK from me - apart from enabling zstd by default.
> > > >
> > > > On 9/13/22 07:37, Etienne Cordonnier via
> > lists.openembedded.org
> > 
> > <https://urldefense.com/v3/__http://lists.openembedded.org__;!!FbZ0ZwI3Qg!t0JG8eQqpsPs8clofb2phwJc6ONCKBjy-iQukKenLRVzBQvJrKTp8VsgKBI7cR8KlV3N64C3fKRHIcFhOF1_vg$>
> > >
> >  
> > <https://urldefense.com/v3/__http://lists.openembedded.org__;!!FbZ0ZwI3Qg!u0KgIth5yNSO1tok49C5_xo0QPHIFLa4kZBl3vVZwB-2Ui1uYBW7nt85fKXXM_VAHZ2LdFx_bxrNjvo$>
> > > wrote:
> > > > > This allows the use of zstd for opkg packages by using
> > > OPKGBUILDCMD:
> > > > > OPKGBUILDCMD = "opkg-build -Z zstd"
> > > > >
> > > > > Signed-off-by: Alex Feinman 
> > > > > Signed-off-by: Etienne Cordonnier 
> > > > > ---
> > > > >   meta/recipes-devtools

Re: [OE-core] [PATCH v3] webkitgtk: Fix build on 32bit arm

[Khem Raj]

On Tue, Sep 13, 2022 at 7:25 PM Yu, Mingli  wrote:
>
> Still failed on beaglebone-yocto:
>
> /build/tmp-glibc/work/cortexa8hf-neon-wrs-linux-gnueabi/webkitgtk/2.36.7-r0/webkitgtk-2.36.7/Source/W
> ebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp:38:8: error:
> standard attributes in middle of decl-specifiers
> 38 | static alignas(16) short s_FELightingConstantsForNeon[] = {
>|^~~
>

What is your -j value ? please give 4GB per core of memory for
webkitgtk to build.

> Thanks,
>
> On 9/9/22 05:45, Khem Raj wrote:
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> >
> > Signed-off-by: Khem Raj 
> > Cc: Mingli Yu 
> > ---
> > v2: Fix commit msg format
> > v3: Apply suggestion from 
> > https://github.com/WebKit/WebKit/pull/1233#discussion_r915217428
> >
> >   ...44e17d258106617b0e6d783d073b188a2548.patch | 296 ++
> >   meta/recipes-sato/webkit/webkitgtk_2.36.7.bb  |   1 +
> >   2 files changed, 297 insertions(+)
> >   create mode 100644 
> > meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
> >
> > diff --git 
> > a/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
> >  
> > b/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
> > new file mode 100644
> > index 00..32f92f7ff5
> > --- /dev/null
> > +++ 
> > b/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
> > @@ -0,0 +1,296 @@
> > +From 0d3344e17d258106617b0e6d783d073b188a2548 Mon Sep 17 00:00:00 2001
> > +From: Adrian Perez de Castro 
> > +Date: Thu, 2 Jun 2022 11:19:06 +0300
> > +Subject: [PATCH] [ARM][NEON] FELightningNEON.cpp fails to build, NEON fast
> > + path seems unused https://bugs.webkit.org/show_bug.cgi?id=241182
> > +
> > +Reviewed by NOBODY (OOPS!).
> > +
> > +Move the NEON fast path for the SVG lighting filter effects into
> > +FELightingSoftwareApplier, and arrange to actually use them by
> > +forwarding calls to applyPlatformGeneric() into applyPlatformNeon().
> > +
> > +Some changes were needed to adapt platformApplyNeon() to the current
> > +state of filters after r286140. This was not detected because the code
> > +bitrotted due to it being guarded with CPU(ARM_TRADITIONAL), which does
> > +not get used much these days: CPU(ARM_THUMB2) is more common. It should
> > +be possible to use the NEON fast paths also in Thumb mode, but that is
> > +left for a follow-up fix.
> > +
> > +* Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp:
> > +(WebCore::FELightingSoftwareApplier::platformApplyNeonWorker):
> > +(WebCore::FELightingSoftwareApplier::getPowerCoefficients):
> > +(WebCore::FELighting::platformApplyNeonWorker): Deleted.
> > +(WebCore::FELighting::getPowerCoefficients): Deleted.
> > +* Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.h:
> > +(WebCore::FELightingSoftwareApplier::applyPlatformNeon):
> > +(WebCore::FELighting::platformApplyNeon): Deleted.
> > +* Source/WebCore/platform/graphics/filters/DistantLightSource.h:
> > +* Source/WebCore/platform/graphics/filters/FELighting.h:
> > +* Source/WebCore/platform/graphics/filters/PointLightSource.h:
> > +* Source/WebCore/platform/graphics/filters/SpotLightSource.h:
> > +* 
> > Source/WebCore/platform/graphics/filters/software/FELightingSoftwareApplier.h:
> > +---
> > +Upstream-Status: Submitted [https://github.com/WebKit/WebKit/pull/1233]
> > +Signed-off-by: Khem Raj 
> > +
> > + .../cpu/arm/filters/FELightingNEON.cpp|  4 +-
> > + .../graphics/cpu/arm/filters/FELightingNEON.h | 54 +--
> > + .../graphics/filters/DistantLightSource.h |  4 ++
> > + .../platform/graphics/filters/FELighting.h|  7 ---
> > + .../graphics/filters/PointLightSource.h   |  4 ++
> > + .../graphics/filters/SpotLightSource.h|  4 ++
> > + .../software/FELightingSoftwareApplier.h  | 16 ++
> > + 7 files changed, 57 insertions(+), 36 deletions(-)
> > +
> > +--- a/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp
> >  b/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp
> > +@@ -49,7 +49,7 @@ short* feLightingConstantsForNeon()
> > + return s_FELightingConstantsForNeon;
> > + }
> > +
> > +-void FELighting::platformApplyNeonWorker(FELightingPaintingDataForNeon* 
> > parameters)
> > ++void 
> > FELightingSoftwareApplier::platformApplyNeonWorker(FELightingPaintingDataForNeon*
> > 

[OE-core] [PATCH v2] elfutils: Enable ptests on musl targets

[Khem Raj]

Signed-off-by: Khem Raj 
---
v2: Install libeu.a into ptest package

 .../elfutils/elfutils_0.187.bb|   4 +-
 ...Add-libeu-to-tests-needing-error-API.patch | 147 ++
 2 files changed, 150 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.187.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.187.bb
index 561112c580..40c51c8814 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.187.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.187.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://run-ptest \
file://ptest.patch \

file://0001-tests-Makefile.am-compile-test_nlist-with-standard-C.patch \
+   file://0001-tests-Add-libeu-to-tests-needing-error-API.patch \
"
 SRC_URI:append:libc-musl = " \
file://0003-musl-utils.patch \
@@ -29,7 +30,6 @@ SRC_URI:append:libc-musl = " \
 SRC_URI[sha256sum] = 
"e70b0dfbe610f90c4d1fe0d71af142a4e25c3c4ef9ebab8d2d72b65159d454c8"
 
 inherit autotools gettext ptest pkgconfig
-PTEST_ENABLED:libc-musl = "0"
 
 EXTRA_OECONF = "--program-prefix=eu-"
 
@@ -66,6 +66,7 @@ do_install_ptest() {
# copy the files which needed by the cases
TEST_FILES="strip strip.o addr2line elfcmp objdump readelf 
size.o nm.o nm elflint elfcompress elfclassify stack unstrip"
install -d -m 755   ${D}${PTEST_PATH}/src
+   install -d -m 755   ${D}${PTEST_PATH}/lib
install -d -m 755   ${D}${PTEST_PATH}/libelf
install -d -m 755   ${D}${PTEST_PATH}/libdw
install -d -m 755   
${D}${PTEST_PATH}/libdwfl
@@ -83,6 +84,7 @@ do_install_ptest() {
cp ${D}${libdir}/libasm-${PV}.so 
${D}${PTEST_PATH}/libasm/libasm.so
cp ${B}/libcpu/libcpu.a ${D}${PTEST_PATH}/libcpu/
cp ${B}/libebl/libebl.a ${D}${PTEST_PATH}/libebl/
+   cp ${B}/lib/libeu.a ${D}${PTEST_PATH}/lib/
cp ${S}/libelf/*.h ${D}${PTEST_PATH}/libelf/
cp ${S}/libdw/*.h  ${D}${PTEST_PATH}/libdw/
cp ${S}/libdwfl/*.h${D}${PTEST_PATH}/libdwfl/
diff --git 
a/meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch
 
b/meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch
new file mode 100644
index 00..7c1bc87cbf
--- /dev/null
+++ 
b/meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch
@@ -0,0 +1,147 @@
+From c05c787070a390a2061bfcb845e1e35e8b1373b3 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Tue, 13 Sep 2022 09:33:00 -0700
+Subject: [PATCH] tests: Add libeu to tests needing error() API
+
+A local error() impelmentation is used when libc does not provide it,
+therefore link in libeu.a which contains this function in tests needing
+error() API
+
+Upstream-Status: Submitted 
[https://sourceware.org/pipermail/elfutils-devel/2022q3/005375.html]
+Signed-off-by: Khem Raj 
+---
+ tests/Makefile.am | 60 +++
+ 1 file changed, 30 insertions(+), 30 deletions(-)
+
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index 3943e17..1acc49b 100644
+--- a/tests/Makefile.am
 b/tests/Makefile.am
+@@ -638,17 +638,17 @@ libeu = ../lib/libeu.a
+ arextract_LDADD = $(libelf)
+ arsymtest_LDADD = $(libelf)
+ newfile_LDADD = $(libelf)
+-saridx_LDADD = $(libelf)
++saridx_LDADD = $(libeu) $(libelf)
+ scnnames_LDADD = $(libelf)
+-sectiondump_LDADD = $(libelf)
++sectiondump_LDADD = $(libeu) $(libelf)
+ showptable_LDADD = $(libelf)
+ hash_LDADD = $(libelf)
+ test_nlist_CFLAGS =-g -O0 $(EXTRA_NLIST_CFLAGS)
+ test_nlist_LDADD = $(libelf)
+ msg_tst_LDADD = $(libelf)
+ newscn_LDADD = $(libelf)
+-early_offscn_LDADD = $(libelf)
+-ecp_LDADD = $(libelf)
++early_offscn_LDADD = $(libeu) $(libelf)
++ecp_LDADD = $(libeu) $(libelf)
+ update1_LDADD = $(libelf)
+ update2_LDADD = $(libelf)
+ update3_LDADD = $(libdw) $(libelf)
+@@ -662,12 +662,12 @@ get_files_LDADD = $(libdw) $(libelf)
+ next_files_LDADD = $(libdw) $(libelf)
+ get_aranges_LDADD = $(libdw) $(libelf)
+ allfcts_LDADD = $(libdw) $(libelf)
+-line2addr_LDADD = $(libdw) $(argp_LDADD)
+-addrscopes_LDADD = $(libdw) $(argp_LDADD)
+-funcscopes_LDADD = $(libdw) $(argp_LDADD)
+-funcretval_LDADD = $(libdw) $(argp_LDADD)
+-allregs_LDADD = $(libdw) $(argp_LDADD)
+-find_prologues_LDADD = $(libdw) $(argp_LDADD)
++line2addr_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++addrscopes_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++funcscopes_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++funcretval_LDADD = $(libeu) $(libdw) $(

Re: [OE-core] [PATCH] opkg: enable zstd support

[Khem Raj]

Thanks for sharing, really appreciate it. How close were compression
rates in numbers ? I think some users might be sensitive to the
archive sizes, if its something
with in acceptable range, I do agree, zstd would be a better default these days.

On Tue, Sep 13, 2022 at 1:20 PM Alex Feinman  wrote:
>
> I do have some numbers. When I was selling this change internally, I did a 
> comparison on our internal build.
>
>   Combined write IPK times (Σ t do_package_write_ipk)
>
> xz 162m 35s
>
> gz 52m 13s
>
> zstd   33m 49s
>
> Compression rate for zstd was closer to xz than to gz but not as good as xz. 
> For systems that have to cache packages on the device with limited storage xz 
> might be a better option, but for the bulk of projects zstd is the best choice
>
> Additionally, zstd offers much faster decompression than xz so the rootfs 
> build step that includes unpacking all of the ipks, takes 3m 58s with xz and 
> 2m 44s with zstd.
>
> One other thing of note - if your build includes debug packages, some may be 
> quite large. E.g. one of our components produces a 2.2 GB debug package 
> (uncompressed). On large files xz requires a disproportionally large amount 
> of time resulting in 15 minutes needed to simply write ipk for the 
> abovementioned packages, whereas zstd took about 45 sec. For frequent tasks 
> like bitbaking a single package this translates in a lot of saved time.
>
> Bottom line - I think making xz a default package compressor was not entirely 
> thought through. gzip or zstd is what the default should be.
>
> One final note: I could not find a reasonable explanation for why opkg-tools 
> require code changes to support a different compressor. BSD tar and GNU tar 
> both can easily accept compressors that they have no idea about (via -I 
> option) because all of them provide a unified command line interface for use 
> in pipes. If this were done similar to tar, we could have used any compressor 
> we wanted, including the multithreaded versions (zstdmt)
>
>
> On Tue, Sep 13, 2022 at 12:43 PM Khem Raj  wrote:
>>
>> On Tue, Sep 13, 2022 at 12:19 PM Alex Stewart  wrote:
>> >
>> > ACK from me - apart from enabling zstd by default.
>> >
>> > On 9/13/22 07:37, Etienne Cordonnier via lists.openembedded.org wrote:
>> > > This allows the use of zstd for opkg packages by using OPKGBUILDCMD:
>> > > OPKGBUILDCMD = "opkg-build -Z zstd"
>> > >
>> > > Signed-off-by: Alex Feinman 
>> > > Signed-off-by: Etienne Cordonnier 
>> > > ---
>> > >   meta/recipes-devtools/opkg/opkg_0.6.0.bb | 3 ++-
>> > >   1 file changed, 2 insertions(+), 1 deletion(-)
>> > >
>> > > diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb 
>> > > b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
>> > > index 7b351e8123..e38d9d6f3f 100644
>> > > --- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
>> > > +++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
>> > > @@ -30,7 +30,7 @@ inherit autotools pkgconfig ptest
>> > >   target_localstatedir := "${localstatedir}"
>> > >   OPKGLIBDIR ??= "${target_localstatedir}/lib"
>> > >
>> > > -PACKAGECONFIG ??= "libsolv"
>> > > +PACKAGECONFIG ??= "libsolv zstd"
>> >
>> > Building in zstd support by default is a little suspect to me.
>> >
>> > Unless I'm mistaken, OE-core will only build xz-compressed IPKs by
>> > default. So zstd support would be unnecessary for a distro integrator
>> > who just uses upstream OE-core.
>> >
>> > For distros which use zstd compression in their packages, I think it
>> > would be more appropriate to overwrite the opkg PACKAGECONFIG in a
>> > .bbappend.
>> >
>>
>> This is perhaps fine. I do wonder if there is some performance
>> comparison data between xz and zstd compressed ipks
>> with opkg, it might help users on making this choice and also if we
>> should consider using
>> zstd by default at some point or not.
>>
>> > Is there something I'm not considering here?
>> >
>> > >
>> > >   PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
>> > >   gnupg gpgme libgpg-error,\
>> > > @@ -39,6 +39,7 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
>> > >   PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
>> > >   PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl 
>> > > openssl"
>&g

Re: [OE-core] [PATCH] opkg: enable zstd support

[Khem Raj]

On Tue, Sep 13, 2022 at 12:19 PM Alex Stewart  wrote:
>
> ACK from me - apart from enabling zstd by default.
>
> On 9/13/22 07:37, Etienne Cordonnier via lists.openembedded.org wrote:
> > This allows the use of zstd for opkg packages by using OPKGBUILDCMD:
> > OPKGBUILDCMD = "opkg-build -Z zstd"
> >
> > Signed-off-by: Alex Feinman 
> > Signed-off-by: Etienne Cordonnier 
> > ---
> >   meta/recipes-devtools/opkg/opkg_0.6.0.bb | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb 
> > b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
> > index 7b351e8123..e38d9d6f3f 100644
> > --- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
> > +++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
> > @@ -30,7 +30,7 @@ inherit autotools pkgconfig ptest
> >   target_localstatedir := "${localstatedir}"
> >   OPKGLIBDIR ??= "${target_localstatedir}/lib"
> >
> > -PACKAGECONFIG ??= "libsolv"
> > +PACKAGECONFIG ??= "libsolv zstd"
>
> Building in zstd support by default is a little suspect to me.
>
> Unless I'm mistaken, OE-core will only build xz-compressed IPKs by
> default. So zstd support would be unnecessary for a distro integrator
> who just uses upstream OE-core.
>
> For distros which use zstd compression in their packages, I think it
> would be more appropriate to overwrite the opkg PACKAGECONFIG in a
> .bbappend.
>

This is perhaps fine. I do wonder if there is some performance
comparison data between xz and zstd compressed ipks
with opkg, it might help users on making this choice and also if we
should consider using
zstd by default at some point or not.

> Is there something I'm not considering here?
>
> >
> >   PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
> >   gnupg gpgme libgpg-error,\
> > @@ -39,6 +39,7 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
> >   PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
> >   PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl 
> > openssl"
> >   PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
> > +PACKAGECONFIG[zstd] = "--enable-zstd,--disable-zstd,zstd"
> >   PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
> >
> >   EXTRA_OECONF:class-native = 
> > "--localstatedir=/${@os.path.relpath('${localstatedir}', 
> > '${STAGING_DIR_NATIVE}')} --sysconfdir=/${@os.path.relpath('${sysconfdir}', 
> > '${STAGING_DIR_NATIVE}')}"
> >
> >
> >
>
> --
> Alex Stewart
> Software Engineer - NI Real-Time OS
> NI (National Instruments)
>
> alex.stew...@ni.com
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170609): 
https://lists.openembedded.org/g/openembedded-core/message/170609
Mute This Topic: https://lists.openembedded.org/mt/93654146/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] [kirkstone] binutils: stable 2.38 branch updates

[Khem Raj]

On Tue, Sep 13, 2022 at 11:42 AM Randy MacLeod
 wrote:
>
> On 2022-09-13 12:59, Khem Raj wrote:
> > On 9/13/22 2:43 AM, Sundeep KOKKONDA wrote:
> >> Hello,
> >> I am planning to take the gcc, glibc & binutils updates to Kirkstone.
> >> I found only the glibc-2.35 branch is having a few updates (given
> >> below).
> >> /f8ad66a4ca nscd: Fix netlink cache invalidation if epoll is used [BZ
> >> #29415]/
> >> /9e960717e1 Apply asm redirections in wchar.h before first use/
> >> /577c2fc7f3 elf: Call __libc_early_init for reused namespaces (bug
> >> 29528)/
> >> /83f1d9851e NEWS: Add entry for bug 28846/
> >> /cbd8685e82 socket: Check lengths before advancing pointer in
> >> CMSG_NXTHDR/
> >> /4bafc4001d alpha: Fix generic brk system call emulation in
> >> __brk_call (bug 29490)/
> >> /37fd2ac665 stdlib: Fixup mbstowcs NULL __dst handling. [BZ #29279]/
> >> /a1ec4157bc stdlib: Remove attr_write from mbstows if dst is NULL
> >> [BZ: 29265]/
> >> /813a8d0171 Update syscall lists for Linux 5.19/
> >> /e200127c6c riscv: Update rv64 libm test ulps/
> >> /8c172a6cb0 dlfcn: Pass caller pointer to static dlopen
> >> implementation (bug 29446)/
>
> Ideally you'd get that in this week since I think that 4.0.4 is being
> built on Monday, September 19th.
>
> CCing Steve in case he missed this thread.
>
>
> >> The binutils-2.38 has no new commits. And, gcc-11.x also not have any
> >> new release after 11.3.
>
> That's good to know. I was just wondering if there was going to be
> gcc-11.4 so this info is timely.

11.4 would be next sprint or early summer of 2023

>
>
> >> In /master/ branch gcc_12.2, glibc_2.36 & binutils_2.39 versions are
> >> used. Kirkstone will continue to use the old versions?
>
>
> To answer this more directly than Khem. ;-)
>
> The Kirkstone branch will NOT update to the versions shown above. Users
> want a stable version
>
> for the supported timeline of a release; some even may be surprised that
> we update from 11.2 to 11.3
> even if it's all bug fixes.
>
>
> >>
> >
> > the glibc fixes are good so go ahead bump the SRCREV to latest on 2.35
> > branch
>
> Agreed.
>
>
> >  major version backports are exceptions. We can consider doing mixin
> > layers if needed for say newer compiler.
>
>
> Answered above.
>
> Thanks Sundeep!
>
> ../Randy
>
>
> >
> >>
> >>
> >> Thanks,
> >> Sundeep K.
> >>
> >>
> >>
> >>
> >
> > 
> >
>
> --
> # Randy MacLeod
> # Wind River Linux
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170606): 
https://lists.openembedded.org/g/openembedded-core/message/170606
Mute This Topic: https://lists.openembedded.org/mt/92739561/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] [kirkstone] binutils: stable 2.38 branch updates

[Khem Raj]

On 9/13/22 2:43 AM, Sundeep KOKKONDA wrote:

Hello,
I am planning to take the gcc, glibc & binutils updates to Kirkstone. I 
found only the glibc-2.35 branch is having a few updates (given below).
/f8ad66a4ca nscd: Fix netlink cache invalidation if epoll is used [BZ 
#29415]/

/9e960717e1 Apply asm redirections in wchar.h before first use/
/577c2fc7f3 elf: Call __libc_early_init for reused namespaces (bug 29528)/
/83f1d9851e NEWS: Add entry for bug 28846/
/cbd8685e82 socket: Check lengths before advancing pointer in CMSG_NXTHDR/
/4bafc4001d alpha: Fix generic brk system call emulation in __brk_call 
(bug 29490)/

/37fd2ac665 stdlib: Fixup mbstowcs NULL __dst handling. [BZ #29279]/
/a1ec4157bc stdlib: Remove attr_write from mbstows if dst is NULL [BZ: 
29265]/

/813a8d0171 Update syscall lists for Linux 5.19/
/e200127c6c riscv: Update rv64 libm test ulps/
/8c172a6cb0 dlfcn: Pass caller pointer to static dlopen implementation 
(bug 29446)/
The binutils-2.38 has no new commits. And, gcc-11.x also not have any 
new release after 11.3.
In /master/ branch gcc_12.2, glibc_2.36 & binutils_2.39 versions are 
used. Kirkstone will continue to use the old versions?




the glibc fixes are good so go ahead bump the SRCREV to latest on 2.35 
branch
 major version backports are exceptions. We can consider doing mixin 
layers if needed for say newer compiler.





Thanks,
Sundeep K.






OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170603): 
https://lists.openembedded.org/g/openembedded-core/message/170603
Mute This Topic: https://lists.openembedded.org/mt/92739561/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-