[OE-core] [PATCH] glibc:drop libcidn package

[Fred Liu]

From: Fred Liu 

libcidn has been dropped since glibc 2.28

Signed-off-by: Fred Liu 
---
 meta/recipes-core/glibc/glibc-package.inc | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 601dedb9fa..571ae7ae09 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -1,6 +1,6 @@
 INHIBIT_SYSROOT_STRIP = "1"
 
-PACKAGES = "${PN}-dbg catchsegv sln nscd ldconfig ldd tzcode glibc-thread-db 
${PN}-pic libcidn libmemusage malloc-debug libnss-db libsegfault 
${PN}-pcprofile libsotruss ${PN} ${PN}-utils glibc-extra-nss ${PN}-dev 
${PN}-staticdev ${PN}-doc ${PN}-src"
+PACKAGES = "${PN}-dbg catchsegv sln nscd ldconfig ldd tzcode glibc-thread-db 
${PN}-pic libmemusage malloc-debug libnss-db libsegfault ${PN}-pcprofile 
libsotruss ${PN} ${PN}-utils glibc-extra-nss ${PN}-dev ${PN}-staticdev 
${PN}-doc ${PN}-src"
 
 # The ld.so in this glibc supports the GNU_HASH
 RPROVIDES:${PN} = "eglibc rtld(GNU_HASH)"
@@ -29,7 +29,6 @@ RRECOMMENDS:${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 
'ldconfig', '${MLPR
 FILES:ldconfig = "${base_sbindir}/ldconfig"
 FILES:ldd = "${bindir}/ldd"
 FILES:libsegfault = "${base_libdir}/libSegFault*"
-FILES:libcidn = "${base_libdir}/libcidn-*.so ${base_libdir}/libcidn.so.*"
 FILES:libmemusage = "${base_libdir}/libmemusage.so"
 FILES:malloc-debug = "${base_libdir}/libc_malloc_debug.so.0"
 FILES:libnss-db = "${base_libdir}/libnss_db.so.* ${base_libdir}/libnss_db-*.so 
${localstatedir}/db/Makefile ${localstatedir}/db/makedbs.sh"
-- 
2.25.1


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

[OE-core][dunfell 00/15] Pull request (cover letter only)

[Steve Sakoman]

The following changes since commit 8e7c8e43260682efafabc50c757b9c2daff98f13:

  connman: add CVE_PRODUCT (2021-09-24 04:27:46 -1000)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next

Minjae Kim (1):
  vim: fix CVE-2021-3778

Ranjitsinh Rathod (1):
  systemd: Add fix for systemd-networkd crash during free

Richard Purdie (7):
  mtd-utils: upgrade 2.1.1 -> 2.1.2
  pybootchart: Avoid divide by zero
  oeqa/qemurunner: Use oe._exit(), not sys.exit()
  libc_package/buildstats: Fix python regex quoting warnings
  oeqa/selftest/gotoolchain: Fix temp file cleanup
  oeqa/buildproject: Ensure temp directories are cleaned up
  glew: Stop polluting /tmp during builds

Robert P. J. Day (1):
  common-licenses: add "Unlicense" license file

Stefano Babic (1):
  mtd-utils: upgrade 2.1.2 -> 2.1.3

Tom Pollard (2):
  bzip2: Update soname for libbz2 1.0.8
  libsamplerate0: Set correct soname for 0.1.9

William A. Kennington III (1):
  rm_work.bbclass: Fix for files starting with -

sana kazi (1):
  openssh: Fix CVE-2021-28041

 meta/classes/libc-package.bbclass |   2 +-
 meta/classes/rm_work.bbclass  |   8 +-
 meta/files/common-licenses/Unlicense  |  24 ++
 meta/lib/buildstats.py|   4 +-
 meta/lib/oeqa/selftest/cases/gotoolchain.py   |   6 +
 meta/lib/oeqa/utils/buildproject.py   |   3 +
 meta/lib/oeqa/utils/qemurunner.py |   2 +-
 meta/lib/oeqa/utils/targetbuild.py|   4 +-
 .../openssh/openssh/CVE-2021-28041.patch  |  20 ++
 .../openssh/openssh_8.2p1.bb  |   1 +
 ...-info-for-ordered-set-new-and-introd.patch |  78 +
 ...dered_set_clear-free-with-destructor.patch |  35 +++
 ...etwork-add-skeleton-of-request-queue.patch | 285 ++
 ...quests-when-link-enters-linger-state.patch |  50 +++
 ...ork-fix-Link-reference-counter-issue.patch | 278 +
 ...nk_drop-and-link_detach_from_manager.patch |  67 
 meta/recipes-core/systemd/systemd_244.5.bb|   6 +
 ...-utils-Fix-return-value-of-ubiformat.patch |  62 
 meta/recipes-devtools/mtd/mtd-utils_git.bb|   9 +-
 meta/recipes-extended/bzip2/bzip2/Makefile.am |   2 +-
 .../glew/glew/notempdir.patch |  19 ++
 meta/recipes-graphics/glew/glew_2.2.0.bb  |   1 +
 .../libsamplerate0/shared_version_info.patch  |  13 +
 .../libsamplerate/libsamplerate0_0.1.9.bb |   1 +
 .../vim/files/CVE-2021-3778.patch |  49 +++
 meta/recipes-support/vim/vim.inc  |   1 +
 scripts/pybootchartgui/pybootchartgui/draw.py |   5 +-
 27 files changed, 956 insertions(+), 79 deletions(-)
 create mode 100644 meta/files/common-licenses/Unlicense
 create mode 100644 
meta/recipes-connectivity/openssh/openssh/CVE-2021-28041.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/basic-pass-allocation-info-for-ordered-set-new-and-introd.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/introduce-ordered_set_clear-free-with-destructor.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/network-add-skeleton-of-request-queue.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/network-also-drop-requests-when-link-enters-linger-state.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/network-fix-Link-reference-counter-issue.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/network-merge-link_drop-and-link_detach_from_manager.patch
 delete mode 100644 
meta/recipes-devtools/mtd/mtd-utils/0001-mtd-utils-Fix-return-value-of-ubiformat.patch
 create mode 100644 meta/recipes-graphics/glew/glew/notempdir.patch
 create mode 100644 
meta/recipes-multimedia/libsamplerate/libsamplerate0/shared_version_info.patch
 create mode 100644 meta/recipes-support/vim/files/CVE-2021-3778.patch

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156704): 
https://lists.openembedded.org/g/openembedded-core/message/156704
Mute This Topic: https://lists.openembedded.org/mt/86134050/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] sstate: Switch to ZStandard compressor support

[Alexandre Belloni]

Hello Henry,

On 04/10/2021 14:38:58+0100, Henry Kleynhans wrote:
> From: Henry Kleynhans 
> 
> This patch switches the compressor from Gzip to ZStandard for ssate cache
> files.
> 
> Zstandard compression provides a significant improvement in
> decompression speed as well as improvement in compression speed and disk
> usage over the 'tgz' format in use.  Furthermore, its configurable
> compression level offers a trade-off between time spent compressing
> sstate cache files and disk space used by those files.  The reduced disk
> usage also contributes to saving network traffic for those sharing their
> sstate cache with others.
> 
> Zstandard should therefore be a good choice when:
> * disk space is at a premium
> * network speed / resources are limited
> * the CI server can sstate packages can be created at high compression
> * less CPU on the build server should be used for sstate decompression
> 
> Signed-off-by: Henry Kleynhans 
> ---
>  meta/classes/sstate.bbclass| 29 ++
>  scripts/sstate-cache-management.sh | 40 +++---
>  2 files changed, 39 insertions(+), 30 deletions(-)
> 
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 92a73114bb..3a67aaba19 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -1,17 +1,19 @@
>  SSTATE_VERSION = "3"
>  
> +SSTATE_ZSTD_CLEVEL = "8"
> +
>  SSTATE_MANIFESTS ?= "${TMPDIR}/sstate-control"
>  SSTATE_MANFILEPREFIX = "${SSTATE_MANIFESTS}/manifest-${SSTATE_MANMACH}-${PN}"
>  
>  def generate_sstatefn(spec, hash, taskname, siginfo, d):
>  if taskname is None:
> return ""
> -extension = ".tgz"
> +extension = ".tar.zst"
>  # 8 chars reserved for siginfo
>  limit = 254 - 8
>  if siginfo:
>  limit = 254
> -extension = ".tgz.siginfo"
> +extension = ".tar.zst.siginfo"
>  if not hash:
>  hash = "INVALID"
>  fn = spec + hash + "_" + taskname + extension
> @@ -37,7 +39,7 @@ SSTATE_PKGNAME= 
> "${SSTATE_EXTRAPATH}${@generate_sstatefn(d.getVar('SSTATE_PK
>  SSTATE_PKG= "${SSTATE_DIR}/${SSTATE_PKGNAME}"
>  SSTATE_EXTRAPATH   = ""
>  SSTATE_EXTRAPATHWILDCARD = ""
> -SSTATE_PATHSPEC   = 
> "${SSTATE_DIR}/${SSTATE_EXTRAPATHWILDCARD}*/*/${SSTATE_PKGSPEC}*_${SSTATE_PATH_CURRTASK}.tgz*"
> +SSTATE_PATHSPEC   = 
> "${SSTATE_DIR}/${SSTATE_EXTRAPATHWILDCARD}*/*/${SSTATE_PKGSPEC}*_${SSTATE_PATH_CURRTASK}.tar.zst*"
>  

I believe this is the cause of those failures:

https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/2671/steps/15/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/2640/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/2662/steps/15/logs/stdio

2021-10-06 12:38:04,114 - oe-selftest - INFO - 
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/lib/oeqa/selftest/cases/sstatetests.py",
 line 117, in test_cleansstate_task_distro_nonspecific
self.run_test_cleansstate_task(['linux-libc-headers'], 
distro_specific=False, distro_nonspecific=True, temp_sstate_location=True)
  File 
"/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/lib/oeqa/selftest/cases/sstatetests.py",
 line 102, in run_test_cleansstate_task
self.assertTrue(tgz_created, msg="Could not find sstate .tgz files for: %s 
(%s)" % (', '.join(map(str, targets)), str(tgz_created)))
  File 
"/home/pokybuild/yocto-worker/oe-selftest-centos/build/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.9/unittest/case.py",
 line 682, in assertTrue
raise self.failureException(msg)
AssertionError: [] is not true : Could not find sstate .tgz files for: 
linux-libc-headers ([])

2021-10-06 12:40:57,420 - oe-selftest - INFO - 
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/lib/oeqa/selftest/cases/sstatetests.py",
 line 158, in test_rebuild_distro_specific_sstate_cross_native_targets
self.run_test_rebuild_distro_specific_sstate(['binutils-cross-' + 
self.tune_arch, 'binutils-native'], temp_sstate_location=True)
  File 
"/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/lib/oeqa/selftest/cases/sstatetests.py",
 line 140, in run_test_rebuild_distro_specific_sstate
self.assertTrue(len(file_tracker_1) >= len(targets), msg = "Not all sstate 
files were created for: %s" % ', '.join(map(str, targets)))
  File 
"/home/pokybuild/yocto-worker/oe-selftest-centos/build/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.9/unittest/case.py",
 line 682, in assertTrue
raise self.failureException(msg)
AssertionError: False is not true : Not all sstate files were created for: 
binutils-cross-x86_64, binutils-native


>  # explicitly make PV to depend on evaluated value of PV variable
>  PV[vardepvalue] = "${PV}"
> @@ -825,23 +827,24 @@ 

Re: [OE-core] [External] Re: SPDX Data Fields in Open Embedded

[Joshua Watt]

On 10/6/21 1:51 PM, Christopher Lusk wrote:


Below you will find a sample of the output that I am generating using 
the create-spdx.bbclass found within oe-core and layers like 
meta-doubleopen:


Sample output:

Text Description automatically generated with medium confidence

The data field names do not match up with those set forth by the Linux 
Foundation for SPDX output related to SBOMs (below), i.e. name should 
appear as PackageName and version information would appear as 
PackageVersion instead of the versionInfo  shown above.


Those fields are when the SPDX document is in "tag" format. We chose to 
write our documents in JSON format because it is much easier to deal 
with programmatically. Even though the JSON format is not described in 
the SPDX documentation, my understanding is that it is an allowed format 
(you can find the schema here: 
https://github.com/spdx/spdx-spec/blob/development/v2.2.2/schemas/spdx-schema.json), 
and most of the SPDX tools are able to handle JSON input as well.



If you really want tag format, I believe there are SPDX tools that can 
convert from JSON to tag format for you



In addition to this, I was curious to know if there are plans to 
update the Yocto where SPDX output would map to and populate all data 
fields related to the NTIA’s minimum and recommended fields for an 
SBOM 
(https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf 
)? 





We have a large amount of SBOM information that we can provide, and I 
think we would like to eventually make it possible to include all of it. 
I cannot say whether that is a sufficient amount of information to 
satisfy any particular government or organization requirements. Someone 
would need to perform an evaluation of each particular set of 
requirements, and ideally share the results back with us.



I am unaware if anyone has evaluated that *specific* document to see if 
what we produce would satisfy the requirements listed there (if they 
have, perhaps they can chime in). If that is something you have interest 
in, you might consider doing that evaluation and sharing it with us; 
from there we can determine what the next steps might be if there are 
areas where we are deficient.




Thanks.



*Christopher D. Lusk*
Product Security Analyst
Product Security Office
Lenovo




emailcl...@lenovo.com 

Lenovo.com 
Twitter |Instagram 
|Facebook 
|Linkedin 
|YouTube 
|Privacy 







*From:* Joshua Watt 
*Sent:* Wednesday, October 6, 2021 10:56 AM
*To:* Christopher Lusk 
*Cc:* openembedded-core@lists.openembedded.org
*Subject:* [External] Re: SPDX Data Fields in Open Embedded

On Wed, Oct 6, 2021 at 9:44 AM Christopher Lusk > wrote:


Hello all,

I am reaching out to inquire about an issue I have experienced as
it relates to SPDX output from the oe-core build process and
specifically the create-spdx.bbclass output.  The data fields in
the output that I have produced do not line up with the SPDX data
field standards (see below) set forth by the Linux Foundation.

My question is if there are plans to update the create-spdx code
so that the output fields align with those set forth by both NTIA
and Linux Foundation?

*SPDX Mapped Field*

PackageSupplier:

PackageName:

PackageVersion:

SPDXID:

Relationship: CONTAINS

Creator:

PackageChecksum:

Can you be a little more specific and possibly provide examples of 
what you are expecting to see and what it is actually generating? We 
are trying to adhere to the SPDX spec, but it is possible there is 
something we misinterpreted or are doing incorrectly.


Source -

https://www.ntia.gov/files/ntia/publications/ntia_sbom_formats_and_standards_whitepaper_-_version_20191025.pdf



Thanks.



*Christopher D. Lusk*
Product Security Analyst
Product Security Office
Lenovo




emailcl...@lenovo.com 

Lenovo.com 

Re: [OE-core] [PATCH] cairo: use ${PN} in package name

[Richard Purdie]

On Wed, 2021-10-06 at 19:22 +, Steven Walter wrote:
> I have reproduced it with 23.0.10

That sounds like dunfell and there have definitely been fixes for this since
dunfell that weren't easily ported into the LTS.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156701): 
https://lists.openembedded.org/g/openembedded-core/message/156701
Mute This Topic: https://lists.openembedded.org/mt/86121102/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: add libmpc-native to DEPENDS

[Khem Raj]

On 10/6/21 3:12 AM, Ross Burton wrote:

On Wed, 6 Oct 2021 at 11:10, Ross Burton  wrote:

This depends on CONFIG_GCC_PLUGINS which I don't believe is enabled in
any of the default configurations.  meta-arm builds a few kernels with
defconfig, which does.


Sorry, brain still not warmed up yet.

CONFIG_GCC_PLUGINS needs to be enabled, but the real difference is
that using the normal GCC pulls libmpc into the sysroot via implicit
dependencies.  If you use an external toolchain (like
meta-arm-toolchain) this doesn't happen, and the dependency needs to
be explicit.



Does it have to be native or target dependency ?


Ross






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156700): 
https://lists.openembedded.org/g/openembedded-core/message/156700
Mute This Topic: https://lists.openembedded.org/mt/86092630/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] cairo: use ${PN} in package name

[Richard Purdie]

On Wed, 2021-10-06 at 17:15 +, Steven Walter wrote:
> Sorry about that, should have included this in the commit message.  I believe
> multilib is required for reproducing the issue.  I have a 32-bit ARM
> multilib.  In that case, ${PN} is lib32-cairo, and so LICENSE gets set on
> lib32-cairo-gobject, but PACKAGES contains cairo-gobject.  As a result the
> effective LICENSE of cairo-gobject is the "default" license for the recipe,
> which is GPL3, which is incorrect.  So when I said "bitbake complains that the
> license is incorrect," I have INCOMPATIBLE_LICENSE = "GPL-3.0", and bitbake
> incorrectly says that I can't use the cairo-gobject package.

Are you testing this with master? If not, which release? I know there were some
multilib issues in this area a while ago but I thought/hoped we'd fixed them.

Both PACKAGES and LICENSE:XXX should get remapped but it sounds like the
incompatible license code is evaluating something too early. That is once reason
why I'd like to check this reproduces with master first.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156699): 
https://lists.openembedded.org/g/openembedded-core/message/156699
Mute This Topic: https://lists.openembedded.org/mt/86121102/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] cairo: use ${PN} in package name

[Richard Purdie]

On Wed, 2021-10-06 at 10:36 -0400, bkyleruss...@gmail.com wrote:
> From: Steven Walter 
> 
> Without this, bitbake complains that the license for cairo-gobject is
> incorrect, because the license is set using ${PN}
> 
> Signed-off-by: Kyle Russell 
> ---
>  meta/recipes-graphics/cairo/cairo_1.16.0.bb | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/recipes-graphics/cairo/cairo_1.16.0.bb 
> b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
> index d76d935c30..b5d4b7eb22 100644
> --- a/meta/recipes-graphics/cairo/cairo_1.16.0.bb
> +++ b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
> @@ -77,17 +77,17 @@ do_install:append () {
>   rmdir -p --ignore-fail-on-non-empty ${D}${libdir}/cairo
>  }
>  
> -PACKAGES =+ "cairo-gobject cairo-script-interpreter cairo-perf-utils"
> +PACKAGES =+ "${PN}-gobject ${PN}-script-interpreter ${PN}-perf-utils"
>  
> -SUMMARY:cairo-gobject = "The Cairo library GObject wrapper library"
> -DESCRIPTION:cairo-gobject = "A GObject wrapper library for the Cairo API."
> +SUMMARY:${PN}-gobject = "The Cairo library GObject wrapper library"
> +DESCRIPTION:${PN}-gobject = "A GObject wrapper library for the Cairo API."
>  
> -SUMMARY:cairo-script-interpreter = "The Cairo library script interpreter"
> -DESCRIPTION:cairo-script-interpreter = "The Cairo script interpreter 
> implements \
> +SUMMARY:${PN}-script-interpreter = "The Cairo library script interpreter"
> +DESCRIPTION:${PN}-script-interpreter = "The Cairo script interpreter 
> implements \
>  CairoScript.  CairoScript is used by tracing utilities to enable the ability 
> \
>  to replay rendering."
>  
> -DESCRIPTION:cairo-perf-utils = "The Cairo library performance utilities"
> +DESCRIPTION:${PN}-perf-utils = "The Cairo library performance utilities"
>  
>  FILES:${PN} = "${libdir}/libcairo.so.*"
>  FILES:${PN}-gobject = "${libdir}/libcairo-gobject.so.*"

How do we reproduce the error? We're not seeing this and this change shouldn't
be needed, PACKAGES just needs to match the variable usage which it does here.
I'd like to understand the issue before we can try and fix it.

Cheers,

Richard


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

[OE-core] [hardknott][PATCH 00/11] Pull request (cover letter only)

[Anuj Mittal]

Please merge these changes.

Thanks,

Anuj

The following changes since commit 97d6a8452779fe511a354a70a72dd338f52a92cb:

  bash: Ensure deterministic build (2021-09-29 16:22:10 +0800)

are available in the Git repository at:

  git://push.openembedded.org/openembedded-core-contrib stable/hardknott-next

Alexander Kanavin (1):
  wic: keep rootfs_size as integer

Anibal Limon (1):
  recipes-support/ptest-runner: Bump to v2.4.2

Chandana kalluri (1):
  scriptutils.py: Add check before deleting path

Chen Qi (1):
  systemd: fix CVE-2021-33910

Jon Mason (1):
  Update mailing list address

Kenfe-Mickael Laventure (1):
  package_ipk: Use localdata store when signing packages

Richard Purdie (3):
  bind: Exclude CVE-2019-6470 from cve-check
  vim: Backport fix for CVE-2021-3770
  glew: Stop polluting /tmp during builds

Sakib Sajal (1):
  qemu: fix CVE-2021-3682

William A. Kennington III (1):
  rm_work.bbclass: Fix for files starting with -

 meta/classes/package_ipk.bbclass  |   4 +-
 meta/classes/rm_work.bbclass  |   8 +-
 meta/conf/distro/include/maintainers.inc  |   2 +-
 .../recipes-connectivity/bind/bind_9.16.16.bb |   4 +
 .../ldconfig-native-2.12.1/ldconfig.patch |   2 +-
 ...it-name-do-not-use-strdupa-on-a-path.patch |  72 ++
 meta/recipes-core/systemd/systemd_247.6.bb|   1 +
 meta/recipes-devtools/qemu/qemu.inc   |   1 +
 .../qemu/qemu/CVE-2021-3682.patch |  41 
 .../glew/glew/notempdir.patch |  19 ++
 meta/recipes-graphics/glew/glew_2.2.0.bb  |   1 +
 ...-runner_2.4.1.bb => ptest-runner_2.4.2.bb} |   2 +-
 ...1e135a16091c93f6f5f7525a5c58fb7ca9f9.patch | 207 ++
 meta/recipes-support/vim/vim.inc  |   2 +
 scripts/lib/scriptutils.py|   3 +-
 scripts/lib/wic/partition.py  |   2 +-
 16 files changed, 360 insertions(+), 11 deletions(-)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-basic-unit-name-do-not-use-strdupa-on-a-path.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3682.patch
 create mode 100644 meta/recipes-graphics/glew/glew/notempdir.patch
 rename meta/recipes-support/ptest-runner/{ptest-runner_2.4.1.bb => 
ptest-runner_2.4.2.bb} (93%)
 create mode 100644 
meta/recipes-support/vim/files/b7081e135a16091c93f6f5f7525a5c58fb7ca9f9.patch

-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156697): 
https://lists.openembedded.org/g/openembedded-core/message/156697
Mute This Topic: https://lists.openembedded.org/mt/86122164/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] SPDX Data Fields in Open Embedded

[Joshua Watt]

On Wed, Oct 6, 2021 at 9:44 AM Christopher Lusk  wrote:

> Hello all,
>
>
>
> I am reaching out to inquire about an issue I have experienced as it
> relates to SPDX output from the oe-core build process and specifically the
> create-spdx.bbclass output.  The data fields in the output that I have
> produced do not line up with the SPDX data field standards (see below) set
> forth by the Linux Foundation.
>
>
>
> My question is if there are plans to update the create-spdx code so that
> the output fields align with those set forth by both NTIA and Linux
> Foundation?
>
>
>
> *SPDX Mapped Field*
>
> PackageSupplier:
>
> PackageName:
>
> PackageVersion:
>
> SPDXID:
>
> Relationship: CONTAINS
>
> Creator:
>
> PackageChecksum:
>
>
>

Can you be a little more specific and possibly provide examples of what you
are expecting to see and what it is actually generating? We are trying to
adhere to the SPDX spec, but it is possible there is something we
misinterpreted or are doing incorrectly.


> Source -
> https://www.ntia.gov/files/ntia/publications/ntia_sbom_formats_and_standards_whitepaper_-_version_20191025.pdf
>
>
>
> Thanks.
> --
>
> *Christopher D. Lusk*
> Product Security Analyst
> Product Security Office
> Lenovo
>
>
> [image: Email]cl...@lenovo.com
>
>
>
> Lenovo.com 
> Twitter  | Instagram
>  | Facebook 
>  | Linkedin  | YouTube
>  | Privacy
> 
>
>
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156696): 
https://lists.openembedded.org/g/openembedded-core/message/156696
Mute This Topic: https://lists.openembedded.org/mt/86121582/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] cairo: use ${PN} in package name

[bkylerussell]

From: Steven Walter 

Without this, bitbake complains that the license for cairo-gobject is
incorrect, because the license is set using ${PN}

Signed-off-by: Kyle Russell 
---
 meta/recipes-graphics/cairo/cairo_1.16.0.bb | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-graphics/cairo/cairo_1.16.0.bb 
b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
index d76d935c30..b5d4b7eb22 100644
--- a/meta/recipes-graphics/cairo/cairo_1.16.0.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
@@ -77,17 +77,17 @@ do_install:append () {
rmdir -p --ignore-fail-on-non-empty ${D}${libdir}/cairo
 }
 
-PACKAGES =+ "cairo-gobject cairo-script-interpreter cairo-perf-utils"
+PACKAGES =+ "${PN}-gobject ${PN}-script-interpreter ${PN}-perf-utils"
 
-SUMMARY:cairo-gobject = "The Cairo library GObject wrapper library"
-DESCRIPTION:cairo-gobject = "A GObject wrapper library for the Cairo API."
+SUMMARY:${PN}-gobject = "The Cairo library GObject wrapper library"
+DESCRIPTION:${PN}-gobject = "A GObject wrapper library for the Cairo API."
 
-SUMMARY:cairo-script-interpreter = "The Cairo library script interpreter"
-DESCRIPTION:cairo-script-interpreter = "The Cairo script interpreter 
implements \
+SUMMARY:${PN}-script-interpreter = "The Cairo library script interpreter"
+DESCRIPTION:${PN}-script-interpreter = "The Cairo script interpreter 
implements \
 CairoScript.  CairoScript is used by tracing utilities to enable the ability \
 to replay rendering."
 
-DESCRIPTION:cairo-perf-utils = "The Cairo library performance utilities"
+DESCRIPTION:${PN}-perf-utils = "The Cairo library performance utilities"
 
 FILES:${PN} = "${libdir}/libcairo.so.*"
 FILES:${PN}-gobject = "${libdir}/libcairo-gobject.so.*"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156695): 
https://lists.openembedded.org/g/openembedded-core/message/156695
Mute This Topic: https://lists.openembedded.org/mt/86121102/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] qemu: Define libnfs PACKAGECONFIG

[Andrei Gherzan]

From: Andrei Gherzan 

The upstream qemu recipe uses host's pkg-config files as a solution to
detecting host's SDL. This has a side effect of using other host
libraries that are later queried by the configure script. This can get
into a situation when the host provides libnfs (for example) and because
later this dependency is not in place anymore, qemu will fail at
runtime.

This change adds a PACKAGECONFIG definition for libnfs that is disabled
by default, in turn disabling the pkgconfig autodetection in configure.

Signed-off-by: Andrei Gherzan 
---
 meta/recipes-devtools/qemu/qemu.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 76e8da159c..4c94060222 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -203,6 +203,8 @@ PACKAGECONFIG[vhost] = 
"--enable-vhost-net,--disable-vhost-net,,"
 PACKAGECONFIG[ust] = 
"--enable-trace-backend=ust,--enable-trace-backend=nop,lttng-ust,"
 PACKAGECONFIG[pie] = "--enable-pie,--disable-pie,,"
 PACKAGECONFIG[seccomp] = "--enable-seccomp,--disable-seccomp,libseccomp"
+# libnfs is currently provided by meta-kodi
+PACKAGECONFIG[libnfs] = "--enable-libnfs,--disable-libnfs,libnfs"
 
 INSANE_SKIP:${PN} = "arch"
 
-- 
2.33.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156694): 
https://lists.openembedded.org/g/openembedded-core/message/156694
Mute This Topic: https://lists.openembedded.org/mt/86117490/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] linux-yocto/5.14: revert: scripts/gcc-plugins: consistently use HOSTCC

[Bruce Ashfield]

From: Bruce Ashfield 

The previously picked up gcc-plugins script wasn't correct and has
been retracted upstream. We do the same in our 5.14 kernel:

c4def465fc44 Revert "scripts/gcc-plugins: consistently use HOSTCC"

Signed-off-by: Bruce Ashfield 
---

This follows my previous patches to add the 5.14 -stable updates to
linux-yocto.

Cheers,

Bruce

 .../linux/linux-yocto-rt_5.14.bb  |  2 +-
 .../linux/linux-yocto-tiny_5.14.bb|  4 ++--
 meta/recipes-kernel/linux/linux-yocto_5.14.bb | 20 +--
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb
index 3088254265..0baffe6f2f 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb
@@ -11,7 +11,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "37f05fcf24a295b1e786e20b16304e5a2592ec99"
+SRCREV_machine ?= "ca5b19aa3996eb1907f546fce7a7fa55053fbead"
 SRCREV_meta ?= "884dfea956ec6b166d1f99a295c47338573a974c"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb
index e262722c5b..5ca45ad894 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb
@@ -15,8 +15,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine:qemuarm ?= "c78d0c7211350419b9262cb2c8b905dcb896c881"
-SRCREV_machine ?= "ab6331a06844991fb4451b329f9f863fd89dfbf8"
+SRCREV_machine:qemuarm ?= "66b3eb63900447948655628e141b54ce0dc3a009"
+SRCREV_machine ?= "c4def465fc44a7f5311d9b942d6cdd33cb4804ca"
 SRCREV_meta ?= "884dfea956ec6b166d1f99a295c47338573a974c"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.14.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.14.bb
index 866c2b6d61..f1d353072c 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.14.bb
@@ -13,16 +13,16 @@ KBRANCH:qemux86  ?= "v5.14/standard/base"
 KBRANCH:qemux86-64 ?= "v5.14/standard/base"
 KBRANCH:qemumips64 ?= "v5.14/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "df81c53a3a7120e2be6600b5f6e14af4cbb99979"
-SRCREV_machine:qemuarm64 ?= "ab6331a06844991fb4451b329f9f863fd89dfbf8"
-SRCREV_machine:qemumips ?= "d656d555d9237f41b1d8ccdbc994b41c6b4ae3b4"
-SRCREV_machine:qemuppc ?= "ab6331a06844991fb4451b329f9f863fd89dfbf8"
-SRCREV_machine:qemuriscv64 ?= "ab6331a06844991fb4451b329f9f863fd89dfbf8"
-SRCREV_machine:qemuriscv32 ?= "ab6331a06844991fb4451b329f9f863fd89dfbf8"
-SRCREV_machine:qemux86 ?= "ab6331a06844991fb4451b329f9f863fd89dfbf8"
-SRCREV_machine:qemux86-64 ?= "ab6331a06844991fb4451b329f9f863fd89dfbf8"
-SRCREV_machine:qemumips64 ?= "56c290d3292823510eded4e3064b11fb1ea3e0ac"
-SRCREV_machine ?= "ab6331a06844991fb4451b329f9f863fd89dfbf8"
+SRCREV_machine:qemuarm ?= "c3a887f62f231d6b31f0209712014f9cbc7fd77e"
+SRCREV_machine:qemuarm64 ?= "c4def465fc44a7f5311d9b942d6cdd33cb4804ca"
+SRCREV_machine:qemumips ?= "77174bdf6581bdb93f0f458601364800670f8531"
+SRCREV_machine:qemuppc ?= "c4def465fc44a7f5311d9b942d6cdd33cb4804ca"
+SRCREV_machine:qemuriscv64 ?= "c4def465fc44a7f5311d9b942d6cdd33cb4804ca"
+SRCREV_machine:qemuriscv32 ?= "c4def465fc44a7f5311d9b942d6cdd33cb4804ca"
+SRCREV_machine:qemux86 ?= "c4def465fc44a7f5311d9b942d6cdd33cb4804ca"
+SRCREV_machine:qemux86-64 ?= "c4def465fc44a7f5311d9b942d6cdd33cb4804ca"
+SRCREV_machine:qemumips64 ?= "e86c3a6ad2fde78ad03e0b899286bf603756207d"
+SRCREV_machine ?= "c4def465fc44a7f5311d9b942d6cdd33cb4804ca"
 SRCREV_meta ?= "884dfea956ec6b166d1f99a295c47338573a974c"
 
 # 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 (#156693): 
https://lists.openembedded.org/g/openembedded-core/message/156693
Mute This Topic: https://lists.openembedded.org/mt/86116937/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 7/7] kernel-yocto: don't apply config metadata patches twice

[Bruce Ashfield]

On Wed, Oct 6, 2021 at 8:14 AM Bruce Ashfield via
lists.openembedded.org
 wrote:
>
> On Wed, Oct 6, 2021 at 5:46 AM Jose Quaresma  wrote:
> >
> > Hi Bruce,
> >
> > Bruce Ashfield  escreveu no dia quarta, 6/10/2021 
> > à(s) 01:12:
> >>
> >> From: Bruce Ashfield 
> >>
> >> Signed-off-by: Bruce Ashfield 
> >> ---
> >>  meta/classes/kernel-yocto.bbclass | 5 -
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/meta/classes/kernel-yocto.bbclass 
> >> b/meta/classes/kernel-yocto.bbclass
> >> index 549dfd97a4..1d5a8cdf29 100644
> >> --- a/meta/classes/kernel-yocto.bbclass
> >> +++ b/meta/classes/kernel-yocto.bbclass
> >> @@ -36,7 +36,10 @@ def find_patches(d,subdir):
> >>  if subdir == patchdir:
> >>  patch_list.append(local)
> >>  else:
> >> -patch_list.append(local)
> >> +# skip the patch if a patchdir was supplied, it won't be 
> >> handled
> >> +# properly
> >> +if not patchdir:
> >> +patch_list.append(local)
> >
> >
> > I think that will be useful to have a warning there when the patchdir was 
> > supplied
>
> Sure, but no one has ever hit this before in the wild, so there are
> none known to be in existence, since if they did exist you'd get an
> error.
>

Actually, as it turns out. I can't warn here (at least not in a user
visible way), since it is only being skipped for a particular run of
my find_sccs/patches python functions. There are other calls to those
same routines that pickup patchdir/subdir patches. So when running the
default collection, we can't warn, otherwise that warning is
incorrect. A log might work via, since that isn't easily visible to
the user and shouldn't alarm anyone.

But again, I'll just carry it locally for a while longer instead.

Cheers,

Bruce

> I'll probably just drop the patch and carry it locally.
>
> Bruce
>
> >
> > Jose
> >
> >>
> >>  return patch_list
> >>
> >> --
> >> 2.19.1
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Best regards,
> >
> > José Quaresma
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

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

[OE-core] [dunfell][PATCH v2] weston: Use systemd notify,

[Pavel Zhukov]

From: Pavel Zhukov 

Using systemd notify fixes the problem with dependency chain in case
if other services depend on running weston.
This change required more robust handling of weston modules arguments
due to custom argument parser impmentation in weston (only last
--modules argument is accepted) and fixes the bug in modules handling
in the weston-start script (only last argument is actually parsed by
weston). Master branch implements systemd-notify thus backport but
doesn't utilize modules anymore so this change is mostly dunfell
specific.

Upstream-status: Backport

Signed-off-by: Pavel Zhukov 
Signed-off-by: Andrei Gherzan 
---
 .../wayland/weston-init/weston-start | 12 
 .../wayland/weston-init/weston@.service  |  6 ++
 .../wayland/weston/systemd-notify.weston-start   |  9 +
 .../wayland/weston/xwayland.weston-start |  3 +--
 meta/recipes-graphics/wayland/weston_8.0.0.bb|  6 ++
 5 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-graphics/wayland/weston/systemd-notify.weston-start

diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start 
b/meta/recipes-graphics/wayland/weston-init/weston-start
index ccc7093425..97471df80d 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -23,6 +23,15 @@ add_openvt_argument() {
openvt_args="$openvt_args $1"
 }
 
+## Add module to --modules argument
+add_weston_module() {
+   if [ -z "${weston_modules}" ]; then
+   weston_modules="--modules "
+   fi;
+   weston_modules="${weston_modules}${1},"
+}
+
+
 if [ -n "$WAYLAND_DISPLAY" ]; then
echo "ERROR: A Wayland compositor is already running, nested Weston 
instance is not supported yet."
exit 1
@@ -65,6 +74,9 @@ if [ -d "$modules_dir" ]; then
# process module
. $m
done
+   if [ -n "${weston_modules}" ]; then
+   add_weston_argument "${weston_modules} "
+   fi;
 fi
 
 if test -z "$XDG_RUNTIME_DIR"; then
diff --git a/meta/recipes-graphics/wayland/weston-init/weston@.service 
b/meta/recipes-graphics/wayland/weston-init/weston@.service
index 39e193014a..70c706d75c 100644
--- a/meta/recipes-graphics/wayland/weston-init/weston@.service
+++ b/meta/recipes-graphics/wayland/weston-init/weston@.service
@@ -1,3 +1,7 @@
+# SPDX-FileCopyrightText: Huawei Inc.
+#
+# SPDX-License-Identifier: Apache-2.0
+
 [Unit]
 Description=Weston Wayland Compositor
 RequiresMountsFor=/run
@@ -5,6 +9,8 @@ Conflicts=plymouth-quit.service
 After=systemd-user-sessions.service plymouth-quit-wait.service
 
 [Service]
+Type=notify
+NotifyAccess=all
 User=%i
 PAMName=login
 EnvironmentFile=-/etc/default/weston
diff --git a/meta/recipes-graphics/wayland/weston/systemd-notify.weston-start 
b/meta/recipes-graphics/wayland/weston/systemd-notify.weston-start
new file mode 100644
index 00..fdb48cb609
--- /dev/null
+++ b/meta/recipes-graphics/wayland/weston/systemd-notify.weston-start
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+# SPDX-FileCopyrightText: Huawei Inc.
+# SPDX-License-Identifier: Apache-2.0
+
+
+if [[ -x "/usr/lib/weston/systemd-notify.so" ]]; then
+   add_weston_module "systemd-notify.so"
+fi
diff --git a/meta/recipes-graphics/wayland/weston/xwayland.weston-start 
b/meta/recipes-graphics/wayland/weston/xwayland.weston-start
index b483c97cf1..22984f50a4 100644
--- a/meta/recipes-graphics/wayland/weston/xwayland.weston-start
+++ b/meta/recipes-graphics/wayland/weston/xwayland.weston-start
@@ -2,6 +2,5 @@
 
 if type Xwayland  >/dev/null 2>/dev/null; then
mkdir -p /tmp/.X11-unix
-
-   add_weston_argument "--modules=xwayland.so"
+   add_weston_module "xwayland.so"
 fi
diff --git a/meta/recipes-graphics/wayland/weston_8.0.0.bb 
b/meta/recipes-graphics/wayland/weston_8.0.0.bb
index 0b383f25f3..2b120d7404 100644
--- a/meta/recipes-graphics/wayland/weston_8.0.0.bb
+++ b/meta/recipes-graphics/wayland/weston_8.0.0.bb
@@ -5,9 +5,11 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d79ee9e66bb0f95d3386a7acae780b70 \
 
file://libweston/compositor.c;endline=27;md5=6c53bbbd99273f4f7c4affa855c33c0a"
 
+
 SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
file://weston.png \
file://weston.desktop \
+   file://systemd-notify.weston-start \
file://xwayland.weston-start \

file://0001-weston-launch-Provide-a-default-version-that-doesn-t.patch \
 "
@@ -101,6 +103,10 @@ do_install_append() {
install -Dm 644 ${WORKDIR}/xwayland.weston-start 
${D}${datadir}/weston-start/xwayland
fi
 
+   if [ "${@bb.utils.contains('PACKAGECONFIG', 'systemd', 'yes', 'no', 
d)}" = "yes" ]; then
+   install -Dm 644 ${WORKDIR}/systemd-notify.weston-start 
${D}${datadir}/weston-start/systemd-notify
+   fi
+
if [ 

Re: [OE-core] [PATCH] linux-yocto: add libmpc-native to DEPENDS

[Bruce Ashfield]

On Wed, Oct 6, 2021 at 7:42 AM Ross Burton  wrote:
>
> I should have put this in the commit message, but here's the failure
> when using an external toolchain:
>
> 2021-10-05 12:52:14 - INFO - | HOSTCXX
> scripts/gcc-plugins/arm_ssp_per_task_plugin.so
> 2021-10-05 12:52:14 - INFO - | In file included from
> /builds/engineering/yocto/meta-arm/work/build/tmp/work-shared/fvp-base-arm32/kernel-source/scripts/gcc-plugins/gcc-common.h:103,
> 2021-10-05 12:52:14 - INFO - | from
> /builds/engineering/yocto/meta-arm/work/build/tmp/work-shared/fvp-base-arm32/kernel-source/scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:
> 02021-10-05 12:52:14 - INFO - |
> /builds/persist/toolchains/gcc-arm-10.3-2021.07-aarch64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.3.1/plugin/include/builtins.h:23:10:
> fatal error: mpc.h: No such file or directory
> 2021-10-05 12:52:14 - INFO - | #include 
> 2021-10-05 12:52:14 - INFO - | ^~~
> 2021-10-05 12:52:14 - INFO - | compilation terminated.

Aha. Yes, that does tell the story. I knew it had to be a compilation
failure, since that is how I picked up the other DEPENDS.

Did we want to tweak the commit message and add linux-yocto-dev to the
patch ? I can have go at that if you want.

Bruce

>
> On Wed, 6 Oct 2021 at 11:12, Ross Burton  wrote:
> >
> > On Wed, 6 Oct 2021 at 11:10, Ross Burton  wrote:
> > > This depends on CONFIG_GCC_PLUGINS which I don't believe is enabled in
> > > any of the default configurations.  meta-arm builds a few kernels with
> > > defconfig, which does.
> >
> > Sorry, brain still not warmed up yet.
> >
> > CONFIG_GCC_PLUGINS needs to be enabled, but the real difference is
> > that using the normal GCC pulls libmpc into the sysroot via implicit
> > dependencies.  If you use an external toolchain (like
> > meta-arm-toolchain) this doesn't happen, and the dependency needs to
> > be explicit.
> >
> > Ross



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156690): 
https://lists.openembedded.org/g/openembedded-core/message/156690
Mute This Topic: https://lists.openembedded.org/mt/86092630/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 7/7] kernel-yocto: don't apply config metadata patches twice

[Bruce Ashfield]

On Wed, Oct 6, 2021 at 5:46 AM Jose Quaresma  wrote:
>
> Hi Bruce,
>
> Bruce Ashfield  escreveu no dia quarta, 6/10/2021 
> à(s) 01:12:
>>
>> From: Bruce Ashfield 
>>
>> Signed-off-by: Bruce Ashfield 
>> ---
>>  meta/classes/kernel-yocto.bbclass | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/kernel-yocto.bbclass 
>> b/meta/classes/kernel-yocto.bbclass
>> index 549dfd97a4..1d5a8cdf29 100644
>> --- a/meta/classes/kernel-yocto.bbclass
>> +++ b/meta/classes/kernel-yocto.bbclass
>> @@ -36,7 +36,10 @@ def find_patches(d,subdir):
>>  if subdir == patchdir:
>>  patch_list.append(local)
>>  else:
>> -patch_list.append(local)
>> +# skip the patch if a patchdir was supplied, it won't be handled
>> +# properly
>> +if not patchdir:
>> +patch_list.append(local)
>
>
> I think that will be useful to have a warning there when the patchdir was 
> supplied

Sure, but no one has ever hit this before in the wild, so there are
none known to be in existence, since if they did exist you'd get an
error.

I'll probably just drop the patch and carry it locally.

Bruce

>
> Jose
>
>>
>>  return patch_list
>>
>> --
>> 2.19.1
>>
>>
>> 
>>
>
>
> --
> Best regards,
>
> José Quaresma



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156689): 
https://lists.openembedded.org/g/openembedded-core/message/156689
Mute This Topic: https://lists.openembedded.org/mt/86108495/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/7] linux-yocto/5.14: scripts/gcc-plugins: consistently use HOSTCC

[Bruce Ashfield]

On Wed, Oct 6, 2021 at 7:05 AM Ross Burton  wrote:
>
> Can you drop this.  Turns out in fixing it, I broke it more!

This particular commit has to stay, since all the -stable kernels are
stacked on top.

But I'll revert, merge it to the branches and send a new SRCREV update
that would follow the -stable bumps.

Bruce

>
> Ross
>
> On Wed, 6 Oct 2021 at 01:12, Bruce Ashfield  wrote:
> >
> > From: Bruce Ashfield 
> >
> > Integrating the following commit(s) to linux-yocto/5.14:
> >
> > 724df5812165 scripts/gcc-plugins: consistently use HOSTCC
> >
> > Signed-off-by: Bruce Ashfield 
> > ---
> >  .../linux/linux-yocto-rt_5.14.bb  |  4 ++--
> >  .../linux/linux-yocto-tiny_5.14.bb|  6 ++---
> >  meta/recipes-kernel/linux/linux-yocto_5.14.bb | 22 +--
> >  3 files changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb 
> > b/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb
> > index a147e632e4..06064706e0 100644
> > --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb
> > +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb
> > @@ -11,8 +11,8 @@ python () {
> >  raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel 
> > to linux-yocto-rt to enable it")
> >  }
> >
> > -SRCREV_machine ?= "7630ebb9fd510cf7aa31b6f1dd472f3b0442afb3"
> > -SRCREV_meta ?= "42d2cf670ed06f42a035611a519ea68e2d26"
> > +SRCREV_machine ?= "87e920626b63515458e304527509289993be2796"
> > +SRCREV_meta ?= "a1e3f40a0f4c5d05d1a6110a42d53eb3c3947ec8"
> >
> >  SRC_URI = 
> > "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
> > 
> > git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.14;destsuffix=${KMETA}"
> > diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb 
> > b/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb
> > index 20ff40d267..699c8c7da0 100644
> > --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb
> > +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb
> > @@ -15,9 +15,9 @@ DEPENDS += "openssl-native util-linux-native"
> >  KMETA = "kernel-meta"
> >  KCONF_BSP_AUDIT_LEVEL = "2"
> >
> > -SRCREV_machine:qemuarm ?= "ee2ccc84e65ade5ba0f8e1a700fba29a755746a1"
> > -SRCREV_machine ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> > -SRCREV_meta ?= "42d2cf670ed06f42a035611a519ea68e2d26"
> > +SRCREV_machine:qemuarm ?= "f956536237159b85f94d70bb9e74b5894e6bf07d"
> > +SRCREV_machine ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> > +SRCREV_meta ?= "a1e3f40a0f4c5d05d1a6110a42d53eb3c3947ec8"
> >
> >  PV = "${LINUX_VERSION}+git${SRCPV}"
> >
> > diff --git a/meta/recipes-kernel/linux/linux-yocto_5.14.bb 
> > b/meta/recipes-kernel/linux/linux-yocto_5.14.bb
> > index 0c6fbff75e..809b6fa066 100644
> > --- a/meta/recipes-kernel/linux/linux-yocto_5.14.bb
> > +++ b/meta/recipes-kernel/linux/linux-yocto_5.14.bb
> > @@ -13,17 +13,17 @@ KBRANCH:qemux86  ?= "v5.14/standard/base"
> >  KBRANCH:qemux86-64 ?= "v5.14/standard/base"
> >  KBRANCH:qemumips64 ?= "v5.14/standard/mti-malta64"
> >
> > -SRCREV_machine:qemuarm ?= "8226a3a65df2dbae0fe71e9ff54cba70a9ba85e5"
> > -SRCREV_machine:qemuarm64 ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> > -SRCREV_machine:qemumips ?= "b5389debd85300e24b877f25c2e90381f1df7678"
> > -SRCREV_machine:qemuppc ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> > -SRCREV_machine:qemuriscv64 ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> > -SRCREV_machine:qemuriscv32 ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> > -SRCREV_machine:qemux86 ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> > -SRCREV_machine:qemux86-64 ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> > -SRCREV_machine:qemumips64 ?= "56cc67b699194944809832f4c8f58b9828f02bf9"
> > -SRCREV_machine ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> > -SRCREV_meta ?= "42d2cf670ed06f42a035611a519ea68e2d26"
> > +SRCREV_machine:qemuarm ?= "139cd4a6ac01e83002011680d9fbb14048c1bc3a"
> > +SRCREV_machine:qemuarm64 ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> > +SRCREV_machine:qemumips ?= "f5a73ebec6f028075220c690bbb121284313ebd3"
> > +SRCREV_machine:qemuppc ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> > +SRCREV_machine:qemuriscv64 ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> > +SRCREV_machine:qemuriscv32 ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> > +SRCREV_machine:qemux86 ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> > +SRCREV_machine:qemux86-64 ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> > +SRCREV_machine:qemumips64 ?= "912fc3d0cf57239e6fe5030b82165b2d6f0632e3"
> > +SRCREV_machine ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> > +SRCREV_meta ?= "a1e3f40a0f4c5d05d1a6110a42d53eb3c3947ec8"
> >
> >  # set your preferred provider of linux-yocto to 'linux-yocto-upstream', 
> > and you'll
> >  # get the /base branch, which is pure upstream -stable, and the 
> > same
> > --
> > 2.19.1
> >
> >
> > 
> >



-- 
- Thou shalt not follow the NULL pointer, for chaos and 

Re: [OE-core] [PATCH] linux-yocto: add libmpc-native to DEPENDS

[Ross Burton]

I should have put this in the commit message, but here's the failure
when using an external toolchain:

2021-10-05 12:52:14 - INFO - | HOSTCXX
scripts/gcc-plugins/arm_ssp_per_task_plugin.so
2021-10-05 12:52:14 - INFO - | In file included from
/builds/engineering/yocto/meta-arm/work/build/tmp/work-shared/fvp-base-arm32/kernel-source/scripts/gcc-plugins/gcc-common.h:103,
2021-10-05 12:52:14 - INFO - | from
/builds/engineering/yocto/meta-arm/work/build/tmp/work-shared/fvp-base-arm32/kernel-source/scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:
02021-10-05 12:52:14 - INFO - |
/builds/persist/toolchains/gcc-arm-10.3-2021.07-aarch64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.3.1/plugin/include/builtins.h:23:10:
fatal error: mpc.h: No such file or directory
2021-10-05 12:52:14 - INFO - | #include 
2021-10-05 12:52:14 - INFO - | ^~~
2021-10-05 12:52:14 - INFO - | compilation terminated.

On Wed, 6 Oct 2021 at 11:12, Ross Burton  wrote:
>
> On Wed, 6 Oct 2021 at 11:10, Ross Burton  wrote:
> > This depends on CONFIG_GCC_PLUGINS which I don't believe is enabled in
> > any of the default configurations.  meta-arm builds a few kernels with
> > defconfig, which does.
>
> Sorry, brain still not warmed up yet.
>
> CONFIG_GCC_PLUGINS needs to be enabled, but the real difference is
> that using the normal GCC pulls libmpc into the sysroot via implicit
> dependencies.  If you use an external toolchain (like
> meta-arm-toolchain) this doesn't happen, and the dependency needs to
> be explicit.
>
> Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156687): 
https://lists.openembedded.org/g/openembedded-core/message/156687
Mute This Topic: https://lists.openembedded.org/mt/86092630/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: add libmpc-native to DEPENDS

[Ross Burton]

On Wed, 6 Oct 2021 at 11:10, Ross Burton  wrote:
> This depends on CONFIG_GCC_PLUGINS which I don't believe is enabled in
> any of the default configurations.  meta-arm builds a few kernels with
> defconfig, which does.

Sorry, brain still not warmed up yet.

CONFIG_GCC_PLUGINS needs to be enabled, but the real difference is
that using the normal GCC pulls libmpc into the sysroot via implicit
dependencies.  If you use an external toolchain (like
meta-arm-toolchain) this doesn't happen, and the dependency needs to
be explicit.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156686): 
https://lists.openembedded.org/g/openembedded-core/message/156686
Mute This Topic: https://lists.openembedded.org/mt/86092630/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: add libmpc-native to DEPENDS

[Ross Burton]

On Wed, 6 Oct 2021 at 01:17, Bruce Ashfield  wrote:
> What's the symptom when the native dependency isn't around ? I'm just
> wondering why none of my tests have picked this up. Is it only showing
> on ARM hosts ? Something else ?
>
> linux-yocto-dev can use this as well,  I can take care of that, if you
> don't have the cycles.
>
> I'm also factoring some of these things into kernel.bbclass, but this
> makes sense in the recipe for now.

This depends on CONFIG_GCC_PLUGINS which I don't believe is enabled in
any of the default configurations.  meta-arm builds a few kernels with
defconfig, which does.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156685): 
https://lists.openembedded.org/g/openembedded-core/message/156685
Mute This Topic: https://lists.openembedded.org/mt/86092630/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/7] linux-yocto/5.14: scripts/gcc-plugins: consistently use HOSTCC

[Ross Burton]

Can you drop this.  Turns out in fixing it, I broke it more!

Ross

On Wed, 6 Oct 2021 at 01:12, Bruce Ashfield  wrote:
>
> From: Bruce Ashfield 
>
> Integrating the following commit(s) to linux-yocto/5.14:
>
> 724df5812165 scripts/gcc-plugins: consistently use HOSTCC
>
> Signed-off-by: Bruce Ashfield 
> ---
>  .../linux/linux-yocto-rt_5.14.bb  |  4 ++--
>  .../linux/linux-yocto-tiny_5.14.bb|  6 ++---
>  meta/recipes-kernel/linux/linux-yocto_5.14.bb | 22 +--
>  3 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb 
> b/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb
> index a147e632e4..06064706e0 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.14.bb
> @@ -11,8 +11,8 @@ python () {
>  raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
> linux-yocto-rt to enable it")
>  }
>
> -SRCREV_machine ?= "7630ebb9fd510cf7aa31b6f1dd472f3b0442afb3"
> -SRCREV_meta ?= "42d2cf670ed06f42a035611a519ea68e2d26"
> +SRCREV_machine ?= "87e920626b63515458e304527509289993be2796"
> +SRCREV_meta ?= "a1e3f40a0f4c5d05d1a6110a42d53eb3c3947ec8"
>
>  SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
> 
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.14;destsuffix=${KMETA}"
> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb 
> b/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb
> index 20ff40d267..699c8c7da0 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.14.bb
> @@ -15,9 +15,9 @@ DEPENDS += "openssl-native util-linux-native"
>  KMETA = "kernel-meta"
>  KCONF_BSP_AUDIT_LEVEL = "2"
>
> -SRCREV_machine:qemuarm ?= "ee2ccc84e65ade5ba0f8e1a700fba29a755746a1"
> -SRCREV_machine ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> -SRCREV_meta ?= "42d2cf670ed06f42a035611a519ea68e2d26"
> +SRCREV_machine:qemuarm ?= "f956536237159b85f94d70bb9e74b5894e6bf07d"
> +SRCREV_machine ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> +SRCREV_meta ?= "a1e3f40a0f4c5d05d1a6110a42d53eb3c3947ec8"
>
>  PV = "${LINUX_VERSION}+git${SRCPV}"
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto_5.14.bb 
> b/meta/recipes-kernel/linux/linux-yocto_5.14.bb
> index 0c6fbff75e..809b6fa066 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_5.14.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_5.14.bb
> @@ -13,17 +13,17 @@ KBRANCH:qemux86  ?= "v5.14/standard/base"
>  KBRANCH:qemux86-64 ?= "v5.14/standard/base"
>  KBRANCH:qemumips64 ?= "v5.14/standard/mti-malta64"
>
> -SRCREV_machine:qemuarm ?= "8226a3a65df2dbae0fe71e9ff54cba70a9ba85e5"
> -SRCREV_machine:qemuarm64 ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> -SRCREV_machine:qemumips ?= "b5389debd85300e24b877f25c2e90381f1df7678"
> -SRCREV_machine:qemuppc ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> -SRCREV_machine:qemuriscv64 ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> -SRCREV_machine:qemuriscv32 ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> -SRCREV_machine:qemux86 ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> -SRCREV_machine:qemux86-64 ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> -SRCREV_machine:qemumips64 ?= "56cc67b699194944809832f4c8f58b9828f02bf9"
> -SRCREV_machine ?= "7ae156be3bdbf033839f7f3ec2e9a0b18818"
> -SRCREV_meta ?= "42d2cf670ed06f42a035611a519ea68e2d26"
> +SRCREV_machine:qemuarm ?= "139cd4a6ac01e83002011680d9fbb14048c1bc3a"
> +SRCREV_machine:qemuarm64 ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> +SRCREV_machine:qemumips ?= "f5a73ebec6f028075220c690bbb121284313ebd3"
> +SRCREV_machine:qemuppc ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> +SRCREV_machine:qemuriscv64 ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> +SRCREV_machine:qemuriscv32 ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> +SRCREV_machine:qemux86 ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> +SRCREV_machine:qemux86-64 ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> +SRCREV_machine:qemumips64 ?= "912fc3d0cf57239e6fe5030b82165b2d6f0632e3"
> +SRCREV_machine ?= "724df5812165b61d20e93866be8f3e7e1e5e6b5c"
> +SRCREV_meta ?= "a1e3f40a0f4c5d05d1a6110a42d53eb3c3947ec8"
>
>  # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
> you'll
>  # get the /base branch, which is pure upstream -stable, and the same
> --
> 2.19.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156684): 
https://lists.openembedded.org/g/openembedded-core/message/156684
Mute This Topic: https://lists.openembedded.org/mt/86108488/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][PATCH] weston-init: Override the systemd service by a notify-based one

[Konrad Weihmann]

Without looking to much into the technical details of this patch,
- it should master first (and then be backported to dunfell)
- the patches to need an Upstream-Status field
- changes should be brought to upstream first (and if rejected then a 
proper explanation has to be provided in the patch metadata)


On 06.10.21 12:00, Pavel Zhukov wrote:

From: Pavel Zhukov 

Using systemd notify, a service dependency would be more robust. This
allows, for example, another service to depend on weston-init without
having to hack a sleep (or similar). This change required more robust
handling of weston modules argument due to custom argument parser
impmentation in weston (only last --modules argument is accepted).

Signed-off-by: Pavel Zhukov 
Signed-off-by: Andrei Gherzan 
---
  .../wayland/weston-init/weston-start | 12 
  .../wayland/weston-init/weston@.service  |  6 ++
  .../wayland/weston/systemd-notify.weston-start   |  9 +
  .../wayland/weston/xwayland.weston-start |  3 +--
  meta/recipes-graphics/wayland/weston_8.0.0.bb|  6 ++
  5 files changed, 34 insertions(+), 2 deletions(-)
  create mode 100644 
meta/recipes-graphics/wayland/weston/systemd-notify.weston-start

diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start 
b/meta/recipes-graphics/wayland/weston-init/weston-start
index ccc7093425..97471df80d 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -23,6 +23,15 @@ add_openvt_argument() {
openvt_args="$openvt_args $1"
  }
  
+## Add module to --modules argument

+add_weston_module() {
+   if [ -z "${weston_modules}" ]; then
+   weston_modules="--modules "
+   fi;
+   weston_modules="${weston_modules}${1},"
+}
+
+
  if [ -n "$WAYLAND_DISPLAY" ]; then
echo "ERROR: A Wayland compositor is already running, nested Weston instance 
is not supported yet."
exit 1
@@ -65,6 +74,9 @@ if [ -d "$modules_dir" ]; then
# process module
. $m
done
+   if [ -n "${weston_modules}" ]; then
+   add_weston_argument "${weston_modules} "
+   fi;
  fi
  
  if test -z "$XDG_RUNTIME_DIR"; then

diff --git a/meta/recipes-graphics/wayland/weston-init/weston@.service 
b/meta/recipes-graphics/wayland/weston-init/weston@.service
index 39e193014a..70c706d75c 100644
--- a/meta/recipes-graphics/wayland/weston-init/weston@.service
+++ b/meta/recipes-graphics/wayland/weston-init/weston@.service
@@ -1,3 +1,7 @@
+# SPDX-FileCopyrightText: Huawei Inc.
+#
+# SPDX-License-Identifier: Apache-2.0
+
  [Unit]
  Description=Weston Wayland Compositor
  RequiresMountsFor=/run
@@ -5,6 +9,8 @@ Conflicts=plymouth-quit.service
  After=systemd-user-sessions.service plymouth-quit-wait.service
  
  [Service]

+Type=notify
+NotifyAccess=all


this can be also achieved with a drop-in file, which is less invasive 
then the proposed change



  User=%i
  PAMName=login
  EnvironmentFile=-/etc/default/weston
diff --git a/meta/recipes-graphics/wayland/weston/systemd-notify.weston-start 
b/meta/recipes-graphics/wayland/weston/systemd-notify.weston-start
new file mode 100644
index 00..fdb48cb609
--- /dev/null
+++ b/meta/recipes-graphics/wayland/weston/systemd-notify.weston-start
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+# SPDX-FileCopyrightText: Huawei Inc.
+# SPDX-License-Identifier: Apache-2.0
+
+
+if [[ -x "/usr/lib/weston/systemd-notify.so" ]]; then
+   add_weston_module "systemd-notify.so"
+fi
diff --git a/meta/recipes-graphics/wayland/weston/xwayland.weston-start 
b/meta/recipes-graphics/wayland/weston/xwayland.weston-start
index b483c97cf1..22984f50a4 100644
--- a/meta/recipes-graphics/wayland/weston/xwayland.weston-start
+++ b/meta/recipes-graphics/wayland/weston/xwayland.weston-start
@@ -2,6 +2,5 @@
  
  if type Xwayland  >/dev/null 2>/dev/null; then

mkdir -p /tmp/.X11-unix
-
-   add_weston_argument "--modules=xwayland.so"
+   add_weston_module "xwayland.so"
  fi
diff --git a/meta/recipes-graphics/wayland/weston_8.0.0.bb 
b/meta/recipes-graphics/wayland/weston_8.0.0.bb
index 0b383f25f3..2b120d7404 100644
--- a/meta/recipes-graphics/wayland/weston_8.0.0.bb
+++ b/meta/recipes-graphics/wayland/weston_8.0.0.bb
@@ -5,9 +5,11 @@ LICENSE = "MIT"
  LIC_FILES_CHKSUM = "file://COPYING;md5=d79ee9e66bb0f95d3386a7acae780b70 \
  
file://libweston/compositor.c;endline=27;md5=6c53bbbd99273f4f7c4affa855c33c0a"
  
+

  SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
 file://weston.png \
 file://weston.desktop \
+   file://systemd-notify.weston-start \
 file://xwayland.weston-start \
 
file://0001-weston-launch-Provide-a-default-version-that-doesn-t.patch \
  "
@@ -101,6 +103,10 @@ do_install_append() {
install -Dm 644 ${WORKDIR}/xwayland.weston-start 

[OE-core] [dunfell][PATCH] weston-init: Override the systemd service by a notify-based one

[Pavel Zhukov]

From: Pavel Zhukov 

Using systemd notify, a service dependency would be more robust. This
allows, for example, another service to depend on weston-init without
having to hack a sleep (or similar). This change required more robust
handling of weston modules argument due to custom argument parser
impmentation in weston (only last --modules argument is accepted).

Signed-off-by: Pavel Zhukov 
Signed-off-by: Andrei Gherzan 
---
 .../wayland/weston-init/weston-start | 12 
 .../wayland/weston-init/weston@.service  |  6 ++
 .../wayland/weston/systemd-notify.weston-start   |  9 +
 .../wayland/weston/xwayland.weston-start |  3 +--
 meta/recipes-graphics/wayland/weston_8.0.0.bb|  6 ++
 5 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-graphics/wayland/weston/systemd-notify.weston-start

diff --git a/meta/recipes-graphics/wayland/weston-init/weston-start 
b/meta/recipes-graphics/wayland/weston-init/weston-start
index ccc7093425..97471df80d 100755
--- a/meta/recipes-graphics/wayland/weston-init/weston-start
+++ b/meta/recipes-graphics/wayland/weston-init/weston-start
@@ -23,6 +23,15 @@ add_openvt_argument() {
openvt_args="$openvt_args $1"
 }
 
+## Add module to --modules argument
+add_weston_module() {
+   if [ -z "${weston_modules}" ]; then
+   weston_modules="--modules "
+   fi;
+   weston_modules="${weston_modules}${1},"
+}
+
+
 if [ -n "$WAYLAND_DISPLAY" ]; then
echo "ERROR: A Wayland compositor is already running, nested Weston 
instance is not supported yet."
exit 1
@@ -65,6 +74,9 @@ if [ -d "$modules_dir" ]; then
# process module
. $m
done
+   if [ -n "${weston_modules}" ]; then
+   add_weston_argument "${weston_modules} "
+   fi;
 fi
 
 if test -z "$XDG_RUNTIME_DIR"; then
diff --git a/meta/recipes-graphics/wayland/weston-init/weston@.service 
b/meta/recipes-graphics/wayland/weston-init/weston@.service
index 39e193014a..70c706d75c 100644
--- a/meta/recipes-graphics/wayland/weston-init/weston@.service
+++ b/meta/recipes-graphics/wayland/weston-init/weston@.service
@@ -1,3 +1,7 @@
+# SPDX-FileCopyrightText: Huawei Inc.
+#
+# SPDX-License-Identifier: Apache-2.0
+
 [Unit]
 Description=Weston Wayland Compositor
 RequiresMountsFor=/run
@@ -5,6 +9,8 @@ Conflicts=plymouth-quit.service
 After=systemd-user-sessions.service plymouth-quit-wait.service
 
 [Service]
+Type=notify
+NotifyAccess=all
 User=%i
 PAMName=login
 EnvironmentFile=-/etc/default/weston
diff --git a/meta/recipes-graphics/wayland/weston/systemd-notify.weston-start 
b/meta/recipes-graphics/wayland/weston/systemd-notify.weston-start
new file mode 100644
index 00..fdb48cb609
--- /dev/null
+++ b/meta/recipes-graphics/wayland/weston/systemd-notify.weston-start
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+# SPDX-FileCopyrightText: Huawei Inc.
+# SPDX-License-Identifier: Apache-2.0
+
+
+if [[ -x "/usr/lib/weston/systemd-notify.so" ]]; then
+   add_weston_module "systemd-notify.so"
+fi
diff --git a/meta/recipes-graphics/wayland/weston/xwayland.weston-start 
b/meta/recipes-graphics/wayland/weston/xwayland.weston-start
index b483c97cf1..22984f50a4 100644
--- a/meta/recipes-graphics/wayland/weston/xwayland.weston-start
+++ b/meta/recipes-graphics/wayland/weston/xwayland.weston-start
@@ -2,6 +2,5 @@
 
 if type Xwayland  >/dev/null 2>/dev/null; then
mkdir -p /tmp/.X11-unix
-
-   add_weston_argument "--modules=xwayland.so"
+   add_weston_module "xwayland.so"
 fi
diff --git a/meta/recipes-graphics/wayland/weston_8.0.0.bb 
b/meta/recipes-graphics/wayland/weston_8.0.0.bb
index 0b383f25f3..2b120d7404 100644
--- a/meta/recipes-graphics/wayland/weston_8.0.0.bb
+++ b/meta/recipes-graphics/wayland/weston_8.0.0.bb
@@ -5,9 +5,11 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d79ee9e66bb0f95d3386a7acae780b70 \
 
file://libweston/compositor.c;endline=27;md5=6c53bbbd99273f4f7c4affa855c33c0a"
 
+
 SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
file://weston.png \
file://weston.desktop \
+   file://systemd-notify.weston-start \
file://xwayland.weston-start \

file://0001-weston-launch-Provide-a-default-version-that-doesn-t.patch \
 "
@@ -101,6 +103,10 @@ do_install_append() {
install -Dm 644 ${WORKDIR}/xwayland.weston-start 
${D}${datadir}/weston-start/xwayland
fi
 
+   if [ "${@bb.utils.contains('PACKAGECONFIG', 'systemd', 'yes', 'no', 
d)}" = "yes" ]; then
+   install -Dm 644 ${WORKDIR}/systemd-notify.weston-start 
${D}${datadir}/weston-start/systemd-notify
+   fi
+
if [ "${@bb.utils.contains('PACKAGECONFIG', 'launch', 'yes', 'no', d)}" 
= "yes" ]; then
chmod u+s ${D}${bindir}/weston-launch
fi
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages 

Re: [OE-core] Improve npm support to run build scripts

[Alexander Kanavin]

The OE landscape is littered with unmaintained or barely maintained layers.
By the looks of things, no one wants to maintain this proposed meta-nodejs
layer either, which involves thousands of recipes, (so far) non-existent
tooling to create and update them in scalable ways, and rigorous testing.
Or such a layer would have already happened.

It's for this reason that I think the shrinkwrapped, self-contained recipe
approach is more viable (even if it comes with its own pain points) and
also matches how node.js community operates  - we can fix the CVE stuff as
well to look into dependencies if that's a concern.

Alex

On Wed, 6 Oct 2021 at 11:43, Konrad Weihmann  wrote:

>
>
> On 06.10.21 11:18, Stefan Herbrechtsmeier wrote:
> > Hi Konrad,
> >
> > Am 05.10.2021 um 21:29 schrieb Konrad Weihmann:
> >>
> >>
> >> On 05.10.21 21:17, Alexander Kanavin wrote:
> >>> On Tue, 5 Oct 2021 at 19:44, Stefan Herbrechtsmeier
> >>>  >>> > wrote:
> >>>
> >>>
> >>>  > A layer with thousands of recipes seems totally intractable.
> >>>
> >>> What is your concern? The high number of dependencies or to
> >>> handle it
> >>> via OE?
> >>>
> >>>
> >>> Generating recipes with a tool means the tool will be custom and
> >>> non-standard, and chances of anyone outside of your company
> >>> understanding, using and contributing to it are rather small. There's
> >>> also the problem of needing multiple versions of the same thing for
> >>> different
> >>> consumer items, which oe doesn't easily support. The link Robert
> >>> provided already exposes some of the pain points with that approach.
> >>>
> >>> I tend to think the best way forward (or least painful at least) is
> >>> to gradually improve what there already is, which is the npm class
> >>> and devtool, and send patches to various upstream njs projects when
> >>> they're using outdated dependencies or otherwise need changing.
> >>>
> >>> Alex
> >>
> >> Just to chime in :-), I like to question this approach of having
> >> multiple versions of the same in an image.
> >> As already outlined npm is horrible in many ways, but using the
> >> lockfile approach multiplies that even more.
> >> But I tend to agree that using the currently available oe-core code
> >> would be suited best for a broader audience
> >
> > But this audience loose the some basic features of OE (ex. version and
> > CVE check) and have to manual fix or ignore the licenses.
> >
> >> - in your own layer you simply can do whatever you like.
> >
> > But this make it impossible to share recipes. Why don't we create a
> > meta-nodejs with a different approach to avoid doing the same thing
> > multiple times.
>
> We could, but we have to think about the costs and ways to properly
> maintain it - and that seems to be the main reason.
> You could come up with a repo of your own and see who is interested in
> joining the development (as I for instance did with a repo for ruby
> gems) - still this would be hosted and maintained outside of core I
> think, due to the limited time and resources available.
>
> And **most important** the repo has to provide its own means of testing/CI.
>
> BTW I remember I had a talk with someone last year about it and putting
> a bunch of angular based apps into an image, with all npms as separate
> recipes resulted in ~100k of files.
>
> so CI and testing has to be extra beefy to make it work - which maybe
> requires a good portion of automation, which then brings me back to
> Alex's suggestion to provide some patches to devtool, if there is a need
> for that.
>
> >
> >> While personally I think in the long run, every npm dependency has to
> >> be provided as a recipe of its own (even I know the costs of that
> >> pretty well)... esp when CVE checking and basic packaging hygiene
> >> should be enforced.
> >
> > Why should OE provide a solution with doesn't support this? I think this
> > is a main feature of OE.
>
> It actually does, but having this lockfile based approach, basically
> crams up all into a single recipe, which makes it a bit harder to check
> and whitelist any false positives or n.a. items, as you might have to do
> it for more than one recipe - but yeah, the basic CVE checking is part
> of core and works as expected
>
> >
> >> Nevertheless for oe-core I wouldn't want to change a lot right now, as
> >> there is simply a valid set of consumers missing that could enable us
> >> to do some proper testing. But yeah fixes/improvements for devtool are
> >> very welcome (also the available docu might need a touch)
> >
> > My problem is that the current approach doesn't support the build of an
> > express or angular application. Does it makes sense to add this feature
> > if we know that some basic OE features are missing (CVE and version
> > check) and fixing bugs is a nightmare?
>
> Just my personal opinion would be, to open up a layer on your own and
> let it grow and mature first before getting it in into core - but
> 

Re: [OE-core] Improve npm support to run build scripts

[Konrad Weihmann]

On 06.10.21 11:18, Stefan Herbrechtsmeier wrote:

Hi Konrad,

Am 05.10.2021 um 21:29 schrieb Konrad Weihmann:



On 05.10.21 21:17, Alexander Kanavin wrote:
On Tue, 5 Oct 2021 at 19:44, Stefan Herbrechtsmeier 
> wrote:



 > A layer with thousands of recipes seems totally intractable.

    What is your concern? The high number of dependencies or to 
handle it

    via OE?


Generating recipes with a tool means the tool will be custom and 
non-standard, and chances of anyone outside of your company
understanding, using and contributing to it are rather small. There's 
also the problem of needing multiple versions of the same thing for 
different
consumer items, which oe doesn't easily support. The link Robert 
provided already exposes some of the pain points with that approach.


I tend to think the best way forward (or least painful at least) is 
to gradually improve what there already is, which is the npm class
and devtool, and send patches to various upstream njs projects when 
they're using outdated dependencies or otherwise need changing.


Alex


Just to chime in :-), I like to question this approach of having 
multiple versions of the same in an image.
As already outlined npm is horrible in many ways, but using the 
lockfile approach multiplies that even more.
But I tend to agree that using the currently available oe-core code 
would be suited best for a broader audience


But this audience loose the some basic features of OE (ex. version and 
CVE check) and have to manual fix or ignore the licenses.



- in your own layer you simply can do whatever you like.


But this make it impossible to share recipes. Why don't we create a 
meta-nodejs with a different approach to avoid doing the same thing 
multiple times.


We could, but we have to think about the costs and ways to properly 
maintain it - and that seems to be the main reason.
You could come up with a repo of your own and see who is interested in 
joining the development (as I for instance did with a repo for ruby 
gems) - still this would be hosted and maintained outside of core I 
think, due to the limited time and resources available.


And **most important** the repo has to provide its own means of testing/CI.

BTW I remember I had a talk with someone last year about it and putting 
a bunch of angular based apps into an image, with all npms as separate 
recipes resulted in ~100k of files.


so CI and testing has to be extra beefy to make it work - which maybe 
requires a good portion of automation, which then brings me back to 
Alex's suggestion to provide some patches to devtool, if there is a need 
for that.




While personally I think in the long run, every npm dependency has to 
be provided as a recipe of its own (even I know the costs of that 
pretty well)... esp when CVE checking and basic packaging hygiene 
should be enforced.


Why should OE provide a solution with doesn't support this? I think this 
is a main feature of OE.


It actually does, but having this lockfile based approach, basically 
crams up all into a single recipe, which makes it a bit harder to check 
and whitelist any false positives or n.a. items, as you might have to do 
it for more than one recipe - but yeah, the basic CVE checking is part 
of core and works as expected




Nevertheless for oe-core I wouldn't want to change a lot right now, as 
there is simply a valid set of consumers missing that could enable us 
to do some proper testing. But yeah fixes/improvements for devtool are 
very welcome (also the available docu might need a touch)


My problem is that the current approach doesn't support the build of an 
express or angular application. Does it makes sense to add this feature 
if we know that some basic OE features are missing (CVE and version 
check) and fixing bugs is a nightmare?


Just my personal opinion would be, to open up a layer on your own and 
let it grow and mature first before getting it in into core - but 
patches to devtool are very welcome


Regards
   Stefan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156680): 
https://lists.openembedded.org/g/openembedded-core/message/156680
Mute This Topic: https://lists.openembedded.org/mt/86089523/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] Improve npm support to run build scripts

[Stefan Herbrechtsmeier]

Hi Konrad,

Am 05.10.2021 um 21:29 schrieb Konrad Weihmann:



On 05.10.21 21:17, Alexander Kanavin wrote:
On Tue, 5 Oct 2021 at 19:44, Stefan Herbrechtsmeier 
> wrote:



 > A layer with thousands of recipes seems totally intractable.

    What is your concern? The high number of dependencies or to handle it
    via OE?


Generating recipes with a tool means the tool will be custom and 
non-standard, and chances of anyone outside of your company
understanding, using and contributing to it are rather small. There's 
also the problem of needing multiple versions of the same thing for 
different
consumer items, which oe doesn't easily support. The link Robert 
provided already exposes some of the pain points with that approach.


I tend to think the best way forward (or least painful at least) is to 
gradually improve what there already is, which is the npm class
and devtool, and send patches to various upstream njs projects when 
they're using outdated dependencies or otherwise need changing.


Alex


Just to chime in :-), I like to question this approach of having 
multiple versions of the same in an image.
As already outlined npm is horrible in many ways, but using the lockfile 
approach multiplies that even more.
But I tend to agree that using the currently available oe-core code 
would be suited best for a broader audience


But this audience loose the some basic features of OE (ex. version and 
CVE check) and have to manual fix or ignore the licenses.


- in your own layer you 
simply can do whatever you like.


But this make it impossible to share recipes. Why don't we create a 
meta-nodejs with a different approach to avoid doing the same thing 
multiple times.


While personally I think in the long run, every npm dependency has to be 
provided as a recipe of its own (even I know the costs of that pretty 
well)... esp when CVE checking and basic packaging hygiene should be 
enforced.


Why should OE provide a solution with doesn't support this? I think this 
is a main feature of OE.


Nevertheless for oe-core I wouldn't want to change a lot right now, as 
there is simply a valid set of consumers missing that could enable us to 
do some proper testing. But yeah fixes/improvements for devtool are very 
welcome (also the available docu might need a touch)


My problem is that the current approach doesn't support the build of an 
express or angular application. Does it makes sense to add this feature 
if we know that some basic OE features are missing (CVE and version 
check) and fixing bugs is a nightmare?


Regards
  Stefan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156679): 
https://lists.openembedded.org/g/openembedded-core/message/156679
Mute This Topic: https://lists.openembedded.org/mt/86089523/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] Improve npm support to run build scripts

[Stefan Herbrechtsmeier]

Hi Alex,

Am 05.10.2021 um 21:17 schrieb Alexander Kanavin:
On Tue, 5 Oct 2021 at 19:44, Stefan Herbrechtsmeier 
> wrote:



 > A layer with thousands of recipes seems totally intractable.

What is your concern? The high number of dependencies or to handle it
via OE?


Generating recipes with a tool means the tool will be custom and 
non-standard, and chances of anyone outside of your company

understanding, using and contributing to it are rather small.


Why can't we extend devtool add / createtool to generate multiple 
recipes? As bonus we can check if a recipe already exist?


There's 
also the problem of needing multiple versions of the same thing for 
different

consumer items, which oe doesn't easily support.


The common approach in OE is to add the (partial) version to the recipe 
name. On the other side the major version of an npm package doesn't 
indicate the real API breakage. The major version is also increased if a 
support for an old Node.js version is dropped.


Furthermore I would extend the approach from the link with a symbolic 
link inside the node_modules of the package itself. This allows a recipe 
to use a specific version. It is also possible to track a map between 
npm (package.json) version and OE name so that the generator could 
select the correct OE DEPENDS. But I haven't the experience how often 
you really need an older version. In my test most of the maintainer 
doesn't update the dependencies or the package is orphan.


The link Robert 
provided already exposes some of the pain points with that approach.


It also exposes the pain points with the current approach.

I tend to think the best way forward (or least painful at least) is to 
gradually improve what there already is, which is the npm class
and devtool, and send patches to various upstream njs projects when 
they're using outdated dependencies or otherwise need changing.


How many patches have you send to upstream npm packages and how many 
were successful?


My feeling is that the chance of success isn't high especially deeper in 
the dependency tree.


Regards
  Stefan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156678): 
https://lists.openembedded.org/g/openembedded-core/message/156678
Mute This Topic: https://lists.openembedded.org/mt/86089523/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] Improve npm support to run build scripts

[Stefan Herbrechtsmeier]

Hi Robert,

Am 05.10.2021 um 20:18 schrieb Robert Berger:

On 05/10/2021 15:48, Stefan Herbrechtsmeier wrote:


Is a layer with more more than 1000 recipes thinkable?


Did you have a look at this[1]?

It says: "For instance I currently am using around 10 NPM-packages, 
those culminated into (currently) 937 recipes that are required to build 
these."


[1] 
https://bitbakesoda.blogspot.com/2020/05/a-different-approach-to-npm-with-yocto.html 


thanks for the link. It matches with my idea.

Regards
  Stefan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156677): 
https://lists.openembedded.org/g/openembedded-core/message/156677
Mute This Topic: https://lists.openembedded.org/mt/86089523/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 7/7] kernel-yocto: don't apply config metadata patches twice

[Jose Quaresma]

Hi Bruce,

Bruce Ashfield  escreveu no dia quarta, 6/10/2021
à(s) 01:12:

> From: Bruce Ashfield 
>
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/classes/kernel-yocto.bbclass | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/kernel-yocto.bbclass
> b/meta/classes/kernel-yocto.bbclass
> index 549dfd97a4..1d5a8cdf29 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -36,7 +36,10 @@ def find_patches(d,subdir):
>  if subdir == patchdir:
>  patch_list.append(local)
>  else:
> -patch_list.append(local)
> +# skip the patch if a patchdir was supplied, it won't be
> handled
> +# properly
> +if not patchdir:
> +patch_list.append(local)
>

I think that will be useful to have a warning there when the patchdir was
supplied

Jose


>  return patch_list
>
> --
> 2.19.1
>
>
> 
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156676): 
https://lists.openembedded.org/g/openembedded-core/message/156676
Mute This Topic: https://lists.openembedded.org/mt/86108495/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] sstate.bbclass: adds warnings for the exceptions of os.utime in siginfo

[Jose Quaresma]

Richard Purdie  escreveu no dia
segunda, 4/10/2021 à(s) 21:03:

> On Mon, 2021-10-04 at 18:59 +0100, Jose Quaresma wrote:
> > I understand the exception for the use cases but I think it would be
> useful
> > to show this to the users. Will it be more appropriate perhaps to log
> this as
> > debug messages?
>
> The trouble is in the situations that is guarding against, the user cannot
> do
> anything about it so warnings definitely aren't appropriate and I'm not
> sure
> debug messages would be welcome either. Those would be less invasive
> though.
>

After your explanation, it is not so useful.


> > I have a final question that I don't understand clearly.
> > Can the omission of these timestamps updates on siginfo invalidate the
> use of
> > the sstate-cache for that task,
> > bitbake-dumpsig can complain about that?
>
> I think there is a misunderstanding here. The timestamps I've been talking
> about
> are part of reproducible builds and the SOURCE_DATE_EPOCH variable and
> code.
> These aim to make the output identical. If the output is identical, hash
> equivalence is more successful and the more successful hash equivalence
> is, the
> more sstate reuse you get.


> The timestamps in this part of the sstate code are simply there to handle
> sstate
> artefact aging (e.g. delete things which haven't been used in X weeks). The
> timestamp change is therefore "nice" but if it doesn't happen, it isn't a
> problem. Hope that helps clarify.
>

Yes, it is true I have misunderstood that part of the reproducible builds
and SOURCE_DATE_EPOCH.
It's hard for me to figure out all the pieces involved in hash equivalence
and sstate handling.
One more detail that I understand better.
Your opinions and explanations always help a lot.

Thank you very much.


> Cheers,
>
> Richard
>
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156675): 
https://lists.openembedded.org/g/openembedded-core/message/156675
Mute This Topic: https://lists.openembedded.org/mt/86052256/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 2/2] kernel-fitimage: use correct kernel image

[Andrej Valek]

Even if initramfs_bundle_path was used, a wrong compression was reflected
in output its template file. Use linux.bin as universal kernel image.
The linux.bin file covers both cases.

Signed-off-by: Andrej Valek 
Signed-off-by: Walter Schweizer 
---
 meta/classes/kernel-fitimage.bbclass | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 886ed13029..8718ce7e16 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -495,22 +495,7 @@ fitimage_assemble() {
fitimage_emit_section_maint $1 imagestart
 
uboot_prep_kimage
-
-   if [ "${INITRAMFS_IMAGE_BUNDLE}" = "1" ]; then
-   
initramfs_bundle_path="arch/"${UBOOT_ARCH}"/boot/"${KERNEL_IMAGETYPE_REPLACEMENT}".initramfs"
-   if [ -e "$initramfs_bundle_path" ]; then
-
-   #
-   # Include the kernel/rootfs bundle.
-   #
-
-   fitimage_emit_section_kernel $1 $kernelcount 
"$initramfs_bundle_path" "$linux_comp"
-   else
-   bbwarn "$initramfs_bundle_pat not found."
-   fi
-   else
-   fitimage_emit_section_kernel $1 $kernelcount linux.bin 
"$linux_comp"
-   fi
+   fitimage_emit_section_kernel $1 $kernelcount linux.bin "$linux_comp"
 
#
# Step 2: Prepare a DTB image section
-- 
2.31.1


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

[Andrej Valek]

- use bash variable notation without {} where possible
  - just to make sure it looks like bash variable not bitbake variable one
- fix indent style in "cat" commands
- replace "! -z" -> "-n"
- make debug info in ramdisk section creation more verbose

Signed-off-by: Andrej Valek 
---
 meta/classes/kernel-fitimage.bbclass | 297 ++-
 meta/classes/uboot-sign.bbclass  |  56 ++---
 2 files changed, 178 insertions(+), 175 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 38e05153e3..886ed13029 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -73,7 +73,7 @@ FIT_SIGN_INDIVIDUAL ?= "0"
 #
 # $1 ... .its filename
 fitimage_emit_fit_header() {
-   cat << EOF >> ${1}
+   cat << EOF >> $1
 /dts-v1/;
 
 / {
@@ -94,24 +94,24 @@ EOF
 fitimage_emit_section_maint() {
case $2 in
imagestart)
-   cat << EOF >> ${1}
+   cat << EOF >> $1
 
 images {
 EOF
;;
confstart)
-   cat << EOF >> ${1}
+   cat << EOF >> $1
 
 configurations {
 EOF
;;
sectend)
-   cat << EOF >> ${1}
+   cat << EOF >> $1
};
 EOF
;;
fitend)
-   cat << EOF >> ${1}
+   cat << EOF >> $1
 };
 EOF
;;
@@ -137,28 +137,28 @@ fitimage_emit_section_kernel() {
awk '$3=="${UBOOT_ENTRYSYMBOL}" {print "0x"$1;exit}'`
fi
 
-   cat << EOF >> ${1}
-kernel-${2} {
+   cat << EOF >> $1
+kernel-$2 {
 description = "Linux kernel";
-data = /incbin/("${3}");
+data = /incbin/("$3");
 type = "kernel";
 arch = "${UBOOT_ARCH}";
 os = "linux";
-compression = "${4}";
+compression = "$4";
 load = <${UBOOT_LOADADDRESS}>;
-entry = <${ENTRYPOINT}>;
+entry = <$ENTRYPOINT>;
 hash-1 {
-algo = "${kernel_csum}";
+algo = "$kernel_csum";
 };
 };
 EOF
 
-   if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a 
-n "${kernel_sign_keyname}" ] ; then
-   sed -i '$ d' ${1}
-   cat << EOF >> ${1}
+   if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a 
-n "$kernel_sign_keyname" ] ; then
+   sed -i '$ d' $1
+   cat << EOF >> $1
 signature-1 {
-algo = "${kernel_csum},${kernel_sign_algo}";
-key-name-hint = "${kernel_sign_keyname}";
+algo = "$kernel_csum,$kernel_sign_algo";
+key-name-hint = "$kernel_sign_keyname";
 };
 };
 EOF
@@ -186,26 +186,26 @@ fitimage_emit_section_dtb() {
elif [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
fi
-   cat << EOF >> ${1}
-fdt-${2} {
+   cat << EOF >> $1
+fdt-$2 {
 description = "Flattened Device Tree blob";
-data = /incbin/("${3}");
+data = /incbin/("$3");
 type = "flat_dt";
 arch = "${UBOOT_ARCH}";
 compression = "none";
-${dtb_loadline}
+$dtb_loadline
 hash-1 {
-algo = "${dtb_csum}";
+algo = "$dtb_csum";
 };
 };
 EOF
 
-   if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a 
-n "${dtb_sign_keyname}" ] ; then
-   sed -i '$ d' ${1}
-   cat << EOF >> ${1}
+   if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a 
-n "$dtb_sign_keyname" ] ; then
+   sed -i '$ d' $1
+   cat << EOF >> $1
 signature-1 {
-algo = "${dtb_csum},${dtb_sign_algo}";
-key-name-hint = "${dtb_sign_keyname}";
+algo = "$dtb_csum,$dtb_sign_algo";
+key-name-hint = "$dtb_sign_keyname";
 };
 };
 EOF
@@ -220,29 +220,29 @@ EOF
 # $3 ... Path to boot script image
 fitimage_emit_section_boot_script() {
 
-bootscr_csum="${FIT_HASH_ALG}"
+   bootscr_csum="${FIT_HASH_ALG}"
bootscr_sign_algo="${FIT_SIGN_ALG}"