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

2022-07-28 Thread Steve Sakoman 
The following changes since commit f1c2e21a28f8ad5dc6ff7b0db877aa22e01a9e00:

  pulseaudio: add m4-native to DEPENDS (2022-07-17 16:59:57 -1000)

are available in the Git repository at:

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

Alexander Kanavin (1):
  gnupg: update 2.3.4 -> 2.3.6

Joshua Watt (1):
  sstatesig: Include all dependencies in SPDX task signatures

Khem Raj (2):
  lua: Backport fix for CVE-2022-33099
  gcc-runtime: Pass -nostartfiles when building dummy libstdc++.so

Ming Liu (1):
  rootfs-postcommands.bbclass: move host-user-contaminated.txt to ${S}

Naveen (1):
  gcc: Backport a fix for gcc bug 105039

Richard Purdie (1):
  vim: Upgrade 9.0.0021 -> 9.0.0063

Sakib Sajal (3):
  dpkg: fix CVE-2022-1664
  go: update v1.17.10 -> v1.17.12
  git: upgrade v2.35.3 -> v2.35.4

Tom Hochstein (1):
  gobject-introspection-data: Disable cache for g-ir-scanner

Yi Zhao (1):
  tiff: Security fixes CVE-2022-1354 and CVE-2022-1355

Yue Tao (1):
  gnupg: upgrade to 2.3.7 to fix CVE-2022-34903

wangmy (2):
  bind: upgrade 9.18.2 -> 9.18.3
  bind: upgrade 9.18.3 -> 9.18.4

 .../gobject-introspection-data.bbclass|   5 +
 meta/classes/rootfs-postcommands.bbclass  |   2 +-
 meta/lib/oe/sstatesig.py  |   9 +
 ...1-avoid-start-failure-with-bind-user.patch |   0
 ...d-V-and-start-log-hide-build-options.patch |   0
 ...ching-for-json-headers-searches-sysr.patch |   0
 .../bind/{bind-9.18.2 => bind-9.18.4}/bind9   |   0
 .../{bind-9.18.2 => bind-9.18.4}/conf.patch   |   0
 .../generate-rndc-key.sh  |   0
 ...t.d-add-support-for-read-only-rootfs.patch |   0
 .../make-etc-initd-bind-stop-work.patch   |   0
 .../named.service |   0
 .../bind/{bind_9.18.2.bb => bind_9.18.4.bb}   |   2 +-
 ...ive-Prevent-directory-traversal-for-.patch | 328 ++
 meta/recipes-devtools/dpkg/dpkg_1.21.4.bb |   1 +
 meta/recipes-devtools/gcc/gcc-11.3.inc|   2 +-
 meta/recipes-devtools/gcc/gcc-runtime.inc |   3 +-
 .../gcc/gcc/0030-rust-recursion-limit.patch   |  92 +
 .../git/{git_2.35.3.bb => git_2.35.4.bb}  |   2 +-
 .../go/{go-1.17.10.inc => go-1.17.12.inc} |   2 +-
 ...1.17.10.bb => go-binary-native_1.17.12.bb} |   4 +-
 17.10.bb => go-cross-canadian_1.17.12.bb} |   0
 ...o-cross_1.17.10.bb => go-cross_1.17.12.bb} |   0
 ...ssdk_1.17.10.bb => go-crosssdk_1.17.12.bb} |   0
 ...native_1.17.10.bb => go-native_1.17.12.bb} |   0
 ...ntime_1.17.10.bb => go-runtime_1.17.12.bb} |   0
 .../go/{go_1.17.10.bb => go_1.17.12.bb}   |   0
 .../lua/lua/CVE-2022-33099.patch  |  61 
 meta/recipes-devtools/lua/lua_5.4.4.bb|   1 +
 .../gobject-introspection_1.72.0.bb   |   3 -
 .../libtiff/tiff/CVE-2022-1354.patch  | 212 +++
 .../libtiff/tiff/CVE-2022-1355.patch  |  62 
 meta/recipes-multimedia/libtiff/tiff_4.3.0.bb |   2 +
 ...-a-custom-value-for-the-location-of-.patch |   6 +-
 .../0003-dirmngr-uses-libgpg-error.patch  |  29 --
 .../gnupg/gnupg/relocate.patch|  18 +-
 .../gnupg/{gnupg_2.3.4.bb => gnupg_2.3.7.bb}  |   3 +-
 .../vim/files/crosscompile.patch  |  51 +++
 meta/recipes-support/vim/files/racefix.patch  |  12 +-
 meta/recipes-support/vim/vim.inc  |   9 +-
 40 files changed, 860 insertions(+), 61 deletions(-)
 rename meta/recipes-connectivity/bind/{bind-9.18.2 => 
bind-9.18.4}/0001-avoid-start-failure-with-bind-user.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.2 => 
bind-9.18.4}/0001-named-lwresd-V-and-start-log-hide-build-options.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.2 => 
bind-9.18.4}/bind-ensure-searching-for-json-headers-searches-sysr.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.2 => bind-9.18.4}/bind9 (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.2 => bind-9.18.4}/conf.patch 
(100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.2 => 
bind-9.18.4}/generate-rndc-key.sh (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.2 => 
bind-9.18.4}/init.d-add-support-for-read-only-rootfs.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.2 => 
bind-9.18.4}/make-etc-initd-bind-stop-work.patch (100%)
 rename meta/recipes-connectivity/bind/{bind-9.18.2 => 
bind-9.18.4}/named.service (100%)
 rename meta/recipes-connectivity/bind/{bind_9.18.2.bb => bind_9.18.4.bb} (98%)
 create mode 100644 
meta/recipes-devtools/dpkg/dpkg/0001-Dpkg-Source-Archive-Prevent-directory-traversal-for-.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc/0030-rust-recursion-limit.patch
 rename meta/recipes-devtools/git/{git_2.35.3.bb => git_2.35.4.bb} (98%)
 rename meta/recipes-devtools/go/{go-1.17.10.inc => go-1.17.12.inc} (92%)
 rename meta/recipes-devtools/go/{go-binary-native_1.17.10.bb => 
go-binary-native_1.17.12.bb} (83%)

Re: [OE-core] [RFC][PATCH] bitbake.conf: introduce LINKER/BUILD_LINKER variables

2022-07-28 Thread Khem Raj 
On Thu, Jul 28, 2022 at 7:41 AM Martin Jansa  wrote:

> * makes it a bit easier to replace ld with ld.bfd or some other
> implementation
>   in LD/BUILD_LD variables without changing this whole variable and without
>   depending on ld-is-gold to set ld symlink to preferred implementation (or
>   when we want to force different one for specific recipe, e.g. forcing bfd
>   where gold fails, like in ltp)


This is fixing bare ld calls but there are perhaps handful of recipes where
bare ld is used in most of the cases we rely on compiler driver to do the
linking and this confuses that use case.


>
> Signed-off-by: Martin Jansa 
> ---
>  meta/conf/bitbake.conf | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 1d36aae8b3..1c2ebf333e 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -553,7 +553,8 @@ export CC = "${CCACHE}${HOST_PREFIX}gcc
> ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
>  export CXX = "${CCACHE}${HOST_PREFIX}g++
> ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
>  export FC = "${CCACHE}${HOST_PREFIX}gfortran
> ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
>  export CPP = "${HOST_PREFIX}gcc -E${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
> -export LD = "${HOST_PREFIX}ld${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}"
> +LINKER = "ld"
> +export LD = "${HOST_PREFIX}${LINKER}${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}"
>  export CCLD = "${CC}"
>  export AR = "${HOST_PREFIX}gcc-ar"
>  export AS = "${HOST_PREFIX}as ${HOST_AS_ARCH}"
> @@ -570,7 +571,8 @@ export BUILD_CC = "${CCACHE}${BUILD_PREFIX}gcc
> ${BUILD_CC_ARCH}"
>  export BUILD_CXX = "${CCACHE}${BUILD_PREFIX}g++ ${BUILD_CC_ARCH}"
>  export BUILD_FC = "${CCACHE}${BUILD_PREFIX}gfortran ${BUILD_CC_ARCH}"
>  export BUILD_CPP = "${BUILD_PREFIX}gcc ${BUILD_CC_ARCH} -E"
> -export BUILD_LD = "${BUILD_PREFIX}ld ${BUILD_LD_ARCH}"
> +BUILD_LINKER = "ld"
> +export BUILD_LD = "${BUILD_PREFIX}${BUILD_LINKER} ${BUILD_LD_ARCH}"
>  export BUILD_CCLD = "${BUILD_PREFIX}gcc ${BUILD_CC_ARCH}"
>  export BUILD_AR = "${BUILD_PREFIX}ar"
>  export BUILD_AS = "${BUILD_PREFIX}as ${BUILD_AS_ARCH}"
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168620): 
https://lists.openembedded.org/g/openembedded-core/message/168620
Mute This Topic: https://lists.openembedded.org/mt/92668261/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] create-spdx: Runs the do_create_spdx task after the do_package_write_*

2022-07-28 Thread Richard Purdie 
On Thu, 2022-07-28 at 15:32 +0100, Jose Quaresma wrote:
> 
> 
> Jose Quaresma via lists.openembedded.org
>  escreveu no dia
> quinta, 28/07/2022 à(s) 12:46:
> > 
> > 
> > Richard Purdie  escreveu no dia
> > quinta, 28/07/2022 à(s) 12:01:
> > > On Thu, 2022-07-28 at 09:54 +0100, Jose Quaresma wrote:
> > > > Otherwise spdx can have references for data that is not packed.
> > > > in the package delivered.
> > > > 
> > > > During do_package_write_ipk task in do_package_ipk some files
> > > > is cleaned up from packages-split directory in the funcion
> > > > cleanupcontrol.
> > > > 
> > > > This also fixes the following race condictions when the
> > > > do_create_spdx
> > > > task runs the add_package_files function and these files is
> > > > been deleted
> > > > at same time in the task do_package_write_ipk:
> > > > 
> > > > ERROR: alsa-topology-conf-1.2.5.1-r0 do_create_spdx: Error
> > > > executing a python function in exec_func_python()
> > > > autogenerated:
> > > > 
> > > > The stack trace of python calls that resulted in this
> > > > exception/failure was:
> > > > File: 'exec_func_python() autogenerated', lineno: 2, function:
> > > > 
> > > >       0001:
> > > >   *** 0002:do_create_spdx(d)
> > > >       0003:
> > > > File: '/srv/oe/build/conf/../../layers/openembedded-
> > > > core/meta/classes/create-spdx.bbclass', lineno: 567, function:
> > > > do_create_spdx
> > > >       0563:           
> > > > package_doc.add_relationship(package_doc, "DESCRIBES",
> > > > spdx_package)
> > > >       0564:
> > > >       0565:            package_archive = deploy_dir_spdx /
> > > > "packages" / (package_doc.name + ".tar.zst")
> > > >       0566:            with optional_tarfile(package_archive,
> > > > archive_packaged) as archive:
> > > >   *** 0567:                package_files = add_package_files(
> > > >       0568:                    d,
> > > >       0569:                    package_doc,
> > > >       0570:                    spdx_package,
> > > >       0571:                    pkgdest / package,
> > > > File: '/srv/oe/build/conf/../../layers/openembedded-
> > > > core/meta/classes/create-spdx.bbclass', lineno: 234, function:
> > > > add_package_files
> > > >       0230:                            info.mtime =
> > > > source_date_epoch
> > > >       0231:
> > > >       0232:                        archive.addfile(info, f)
> > > >       0233:
> > > >   *** 0234:                sha1 = bb.utils.sha1_file(filepath)
> > > >       0235:                sha1s.append(sha1)
> > > >       0236:               
> > > > spdx_file.checksums.append(oe.spdx.SPDXChecksum(
> > > >       0237:                        algorithm="SHA1",
> > > >       0238:                        checksumValue=sha1,
> > > > File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 559, function:
> > > > sha1_file
> > > >       0555:    """
> > > >       0556:    Return the hex string representation of the SHA1
> > > > checksum of the filename
> > > >       0557:    """
> > > >       0558:    import hashlib
> > > >   *** 0559:    return _hasher(hashlib.sha1(), filename)
> > > >       0560:
> > > >       0561:def sha384_file(filename):
> > > >       0562:    """
> > > >       0563:    Return the hex string representation of the
> > > > SHA384 checksum of the filename
> > > > File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 528, function:
> > > > _hasher
> > > >       0524:
> > > >       0525:def _hasher(method, filename):
> > > >       0526:    import mmap
> > > >       0527:
> > > >   *** 0528:    with open(filename, "rb") as f:
> > > >       0529:        try:
> > > >       0530:            with mmap.mmap(f.fileno(), 0,
> > > > access=mmap.ACCESS_READ) as mm:
> > > >       0531:                for chunk in iter(lambda:
> > > > mm.read(8192), b''):
> > > >       0532:                    method.update(chunk)
> > > > Exception: FileNotFoundError: [Errno 2] No such file or
> > > > directory: '/srv/oe/build/tmp-lmp/work/all-lmp-linux/alsa-
> > > > topology-conf/1.2.5.1-r0/packages-split/alsa-topology-
> > > > conf/CONTROL/control'
> > > 
> > > We have other places where we've had to teach the code to ignore
> > > the
> > > control files and we'll probably have to do that here (grep for
> > > CONTROL).
> > > 
> > 
> > 
> > The snip that delete this files is in cleanupcontrol
> > https://git.yoctoproject.org/poky/tree/meta/classes/package_ipk.bbclass#n51
> > 
> > So these files are not shipped in the ipk package produced.
> > 
> 
> 
> What I mean is those files are not part of the content deployed and
> it is a requirement of the packing
> standard used so tracking it the sbom doesn't make much sense imo.

Right, it would be fine to make the spdx class skip them if they were
present.

> ar -xv deploy/ipk/all/alsa-topology-conf_1.2.5.1-r0_all.ipk
> x - debian-binary
> x - control.tar.gz
> x - data.tar.xz
> 
> For and deb and ipk we have in deb_write_pkg and ipk_write_pkg:
>         
>     finally:
>         cleanupcontrol(root)
>         bb.utils.unlockfile(lf)
> 
>

Re: [OE-core] [PATCH RFC v2] rust: Rework and improve so SDK and target versions work

2022-07-28 Thread Richard Purdie 
On Thu, 2022-07-28 at 21:56 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Tue, 2022-07-26 at 15:02 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > This patch:
> > * Uses RUST_{BUILD|HOST|TARGET}_SYS everywhere consistently within rust 
> > context
> > * Moves the on target libraries to rust's "sysroot" layout so the SDK can 
> > find
> >   libraries without prompting
> > * Moves the target SDK libraries into the target sysroot rather than the 
> > native one
> > * Enables the target rustc compiler to be built
> > * Replaces cargo-cross-canadian with nativesdk-cargo
> > 
> > * Drops rust-cross-XXX and uses rust-target-config to generate json config
> >   in each WORKDIR
> > * Add nativeksdk-rust as the SDK compiler
> > * Simplifies rust-cross-canadian-XXX to be the environment and json config
> >   for the target only (no binaries)
> > * Drop rust-crosssdk since it isnt needed now
> > * Drop a lot of the virtual/ compiler dependency mess since we don't need it
> > * Cargo cross-canadian environment config is compiled with 
> > rust-cross-canadian
> > * Adds RUST_{BUILD|HOST|TARGET}_SYS to the variable ignore list for hash 
> > purposes
> >   (since it should be accounted for in the build paths)
> > * Adds a slightly hacky approach to make target llvm-config work which 
> > removes
> >   the need for patching llvm.
> > * Drop rust-tools-cross-canadian and just build the tools as part of the 
> > main
> >   rust/nativesdk-rust recipe to avoid rebuilding large chunks of the 
> > toolchain
> > 
> > Work still remaining:
> > * Fully clean up the dependency simplification and removal of the virutal/
> >   code.
> > * Remove RUST_TARGETGENS since I think it is the same everywhere now
> > * The rust recipe doesn't need to always build stage0
> > * The rust recipe doesn't need to always build libstd-rs since
> >   we have a separate recipe. May drop the separate recipe and just copy
> >   the pieces out of the target rust build
> > * Maybe drop RUSTC variable, not sure it is used?
> > * Delete now unneeded rust-llvm llcm-config patch
> > 
> > Adding to an SDK looks like: TOOLCHAIN_LANGS += "rust"
> > 
> > Known issues:
> > * rust target compiler fails for musl:
> >   https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/5574
> >   https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/5588
> > * rust target packages have buildpaths warnings:
> >   
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/5585/steps/11/logs/stdio
> > * mips n32 target rust config and libstd-rs fails:
> >   https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5607
> > * May be multilib variant issues:
> >   https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/5503
> >   https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/3280
> > * Sundeep reported ld loader symbol relocation issues for libstdc++
> > * Breaks mingw build as currently configured
> >   https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/5591
> 
> The patches in master-next further tweak and improve things. I have
> fixed the musl issue and many of the buildpaths ones as well as
> multilib and mingw. This means that we have remaining:
> 
> 1) buildpaths warnings:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/5606
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/5602
> https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/3294
> [and likely a few more as the build completes]
> down to two issues:
> stdio: WARNING: rust-1.62.0-r0 do_package_qa: QA Issue: File 
> /usr/bin/clippy-driver in package rust-tools-clippy contains reference to 
> TMPDIR [buildpaths]
> stdio: WARNING: rust-1.62.0-r0 do_package_qa: QA Issue: File 
> /usr/lib64/librustc_driver-ba615092564ddb01.so in package rust contains 
> reference to TMPDIR [buildpaths]
> stdio: WARNING: lib32-rust-1.62.0-r0 do_package_qa: QA Issue: File 
> /usr/lib/librustc_driver-a9887d06b965b287.so in package lib32-rust contains 
> reference to TMPDIR [buildpaths]
> stdio: WARNING: lib32-rust-1.62.0-r0 do_package_qa: QA Issue: File 
> /usr/bin/clippy-driver in package lib32-rust-tools-clippy contains reference 
> to TMPDIR [buildpaths]
> 
> clippy appears to have a sysroot path encoded into it, the rustc-driver
> is a path to llvm-config. I did try setting SYSROOT as an environment
> variable when building clippy with no success. I also tried making the
> llvm-config a script found via PATH but that failed to build. We may
> need to patch rust to deal with these.
> 
> 
> 2) mips n32 issue:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5624/steps/25/logs/stdio
> > LLVM ERROR: Not supported instr:   > Reg:338>>
> > LLVM ERROR: Not supported instr:   > Reg:1>>
> > warning: `libc` (lib) generated 2 warnings (2 duplicates)
> 
> when building libstd-rs which may mean my guesses at the target data options 
> are still wrong.
> 
> 
> 3)

Re: [OE-core] [PATCH RFC v2] rust: Rework and improve so SDK and target versions work

2022-07-28 Thread Richard Purdie 
On Tue, 2022-07-26 at 15:02 +0100, Richard Purdie via
lists.openembedded.org wrote:
> This patch:
> * Uses RUST_{BUILD|HOST|TARGET}_SYS everywhere consistently within rust 
> context
> * Moves the on target libraries to rust's "sysroot" layout so the SDK can find
>   libraries without prompting
> * Moves the target SDK libraries into the target sysroot rather than the 
> native one
> * Enables the target rustc compiler to be built
> * Replaces cargo-cross-canadian with nativesdk-cargo
> 
> * Drops rust-cross-XXX and uses rust-target-config to generate json config
>   in each WORKDIR
> * Add nativeksdk-rust as the SDK compiler
> * Simplifies rust-cross-canadian-XXX to be the environment and json config
>   for the target only (no binaries)
> * Drop rust-crosssdk since it isnt needed now
> * Drop a lot of the virtual/ compiler dependency mess since we don't need it
> * Cargo cross-canadian environment config is compiled with rust-cross-canadian
> * Adds RUST_{BUILD|HOST|TARGET}_SYS to the variable ignore list for hash 
> purposes
>   (since it should be accounted for in the build paths)
> * Adds a slightly hacky approach to make target llvm-config work which removes
>   the need for patching llvm.
> * Drop rust-tools-cross-canadian and just build the tools as part of the main
>   rust/nativesdk-rust recipe to avoid rebuilding large chunks of the toolchain
> 
> Work still remaining:
> * Fully clean up the dependency simplification and removal of the virutal/
>   code.
> * Remove RUST_TARGETGENS since I think it is the same everywhere now
> * The rust recipe doesn't need to always build stage0
> * The rust recipe doesn't need to always build libstd-rs since
>   we have a separate recipe. May drop the separate recipe and just copy
>   the pieces out of the target rust build
> * Maybe drop RUSTC variable, not sure it is used?
> * Delete now unneeded rust-llvm llcm-config patch
> 
> Adding to an SDK looks like: TOOLCHAIN_LANGS += "rust"
> 
> Known issues:
> * rust target compiler fails for musl:
>   https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/5574
>   https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/5588
> * rust target packages have buildpaths warnings:
>   
> https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/5585/steps/11/logs/stdio
> * mips n32 target rust config and libstd-rs fails:
>   https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5607
> * May be multilib variant issues:
>   https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/5503
>   https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/3280
> * Sundeep reported ld loader symbol relocation issues for libstdc++
> * Breaks mingw build as currently configured
>   https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/5591

The patches in master-next further tweak and improve things. I have
fixed the musl issue and many of the buildpaths ones as well as
multilib and mingw. This means that we have remaining:

1) buildpaths warnings:
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/5606

https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/5602
https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/3294
[and likely a few more as the build completes]
down to two issues:
stdio: WARNING: rust-1.62.0-r0 do_package_qa: QA Issue: File 
/usr/bin/clippy-driver in package rust-tools-clippy contains reference to 
TMPDIR [buildpaths]
stdio: WARNING: rust-1.62.0-r0 do_package_qa: QA Issue: File 
/usr/lib64/librustc_driver-ba615092564ddb01.so in package rust contains 
reference to TMPDIR [buildpaths]
stdio: WARNING: lib32-rust-1.62.0-r0 do_package_qa: QA Issue: File 
/usr/lib/librustc_driver-a9887d06b965b287.so in package lib32-rust contains 
reference to TMPDIR [buildpaths]
stdio: WARNING: lib32-rust-1.62.0-r0 do_package_qa: QA Issue: File 
/usr/bin/clippy-driver in package lib32-rust-tools-clippy contains reference to 
TMPDIR [buildpaths]

clippy appears to have a sysroot path encoded into it, the rustc-driver
is a path to llvm-config. I did try setting SYSROOT as an environment
variable when building clippy with no success. I also tried making the
llvm-config a script found via PATH but that failed to build. We may
need to patch rust to deal with these.


2) mips n32 issue:
https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5624/steps/25/logs/stdio
| LLVM ERROR: Not supported instr:  >
| LLVM ERROR: Not supported instr:  >
| warning: `libc` (lib) generated 2 warnings (2 duplicates)

when building libstd-rs which may mean my guesses at the target data options 
are still wrong.


3) Sundeep reported ld loader symbol relocation issues for libstdc++



Fixing 1) is the priority as with that we can prepare the series for
submission/review/merging. I'm taking some time away for the next few
days so if anyone else wants to fix those...! :)

3) probably needs retesting against the current patches. For 2), not

Re: [OE-core] [PATCH] uboot-config.bbclass: Raise error for bad key

2022-07-28 Thread Otavio Salvador 
Em qui., 28 de jul. de 2022 às 15:44, Tom Hochstein 
escreveu:

> If an invalid key is used, the class ignores the error, with an
> indeterminate result. In my case, the problem surfaced in do_deploy:
>
> ```
> | cp: cannot stat
> '/.../build/tmp/work/imx6qdlsabresd-fsl-linux-gnueabi/u-boot-imx-mfgtool/2022.04-r0/deploy-u-boot-imx-mfgtool/u-boot.imx':
> No such file or
> | directory
> ```
>
> The root cause of this was that the uboot config key did not match
> a valid option. With the fix, the error is caught by the class:
>
> ```
> ERROR: Nothing PROVIDES 'u-boot-imx-mfgtool'
> u-boot-imx-mfgtool was skipped: The selected UBOOT_CONFIG key ['mfgtool']
> has no match in dict_keys(['sd-fslc', 'sd-imx', 'sd-optee-imx', 'sata-imx',
> 'mfgtool-imx']).
> ```
>
> Signed-off-by: Tom Hochstein 
>

Acked-by: Otavio Salvador 

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

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

Re: [OE-core][kirkstone 13/15] gobject-introspection-data: Disable cache for g-ir-scanner

2022-07-28 Thread Chuck Wolber 
On Thu, Jul 28, 2022 at 11:37 AM Steve Sakoman  wrote:

> On Thu, Jul 28, 2022 at 7:55 AM Chuck Wolber 
> wrote:
> >
> > FWIW, the gobject-introspection-native recipe was one of the "canaries
> in the mine" that reliably caused an image build to die while I was
> actively encountering this GCC10 compiler issue in Hardknott:
>
> Have you encountered this issue with Kirkstone?
>

We have not tried yet. We are debating the Hardknott to Kirkstone upgrade
question right now.

Our build is complex and 2.6 (Thud) -> 3.3 (Hardknott) took two months of
very intensive work and then six months of stabilization. Granted python2
-> python3 was part of that, so a big chunk of the stabilization damage was
self-inflicted. I do not expect anything as major for Hardknott ->
Kirkstone, but I am also not naïve either - all blockpoint upgrades are
painful in their own way...

..Ch:W..


-- 
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168615): 
https://lists.openembedded.org/g/openembedded-core/message/168615
Mute This Topic: https://lists.openembedded.org/mt/92640670/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] uboot-config.bbclass: Raise error for bad key

2022-07-28 Thread Tom Hochstein 
If an invalid key is used, the class ignores the error, with an
indeterminate result. In my case, the problem surfaced in do_deploy:

```
| cp: cannot stat 
'/.../build/tmp/work/imx6qdlsabresd-fsl-linux-gnueabi/u-boot-imx-mfgtool/2022.04-r0/deploy-u-boot-imx-mfgtool/u-boot.imx':
 No such file or
| directory
```

The root cause of this was that the uboot config key did not match
a valid option. With the fix, the error is caught by the class:

```
ERROR: Nothing PROVIDES 'u-boot-imx-mfgtool'
u-boot-imx-mfgtool was skipped: The selected UBOOT_CONFIG key ['mfgtool'] has 
no match in dict_keys(['sd-fslc', 'sd-imx', 'sd-optee-imx', 'sata-imx', 
'mfgtool-imx']).
```

Signed-off-by: Tom Hochstein 
---
 meta/classes/uboot-config.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/uboot-config.bbclass 
b/meta/classes/uboot-config.bbclass
index b9ad35821a..e8da8c7452 100644
--- a/meta/classes/uboot-config.bbclass
+++ b/meta/classes/uboot-config.bbclass
@@ -125,5 +125,6 @@ python () {
 else:
 bb.debug(1, "Appending '%s' to UBOOT_BINARIES." % 
ubootbinary)
 d.appendVar('UBOOT_BINARIES', ' ' + ubootbinary)
-break
+return
+raise bb.parse.SkipRecipe("The selected UBOOT_CONFIG key %s has no 
match in %s." % (ubootconfig, ubootconfigflags.keys()))
 }
-- 
2.25.1


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

Re: [OE-core][kirkstone 13/15] gobject-introspection-data: Disable cache for g-ir-scanner

2022-07-28 Thread Steve Sakoman 
On Thu, Jul 28, 2022 at 7:55 AM Chuck Wolber  wrote:
>
> FWIW, the gobject-introspection-native recipe was one of the "canaries in the 
> mine" that reliably caused an image build to die while I was actively 
> encountering this GCC10 compiler issue in Hardknott:

Have you encountered this issue with Kirkstone?

Steve

>
> https://www.mail-archive.com/yocto@lists.yoctoproject.org/msg06163.html
> https://lists.yoctoproject.org/g/yocto/message/53971
>
> Upon re-reading my post, I regret that I did not mention this fact. The 
> production image recipe I was working on at the time did not happen to 
> involve gobject-introspection-native, so I overlooked it. Our other image 
> recipes *DID* invoke gobject-introspection-native, but those were not as 
> immediately important at the time, and I was trying to keep the problem 
> description as focused as possible.
>
> I do not expect this reply to result in anything materially relevant to the 
> problem (it still exists, but we use buildtools to get around it) other than 
> to add more data that may be relevant to someone googling something similar 
> in the future.
>
> ..Ch:W..
>
> On Tue, Jul 26, 2022 at 5:41 PM Steve Sakoman  wrote:
>>
>> From: Tom Hochstein 
>>
>> An intermittent failure occurs in libical-native do_compile:
>>
>> | Traceback (most recent call last):
>> |   File 
>> "/.../build/tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
>>  line 813, in move
>> | os.rename(src, real_dst)
>> | OSError: [Errno 18] Invalid cross-device link: 
>> '/tmp/g-ir-scanner-cache-adxo_2bq' -> 
>> '/home/bamboo/.cache/g-ir-scanner/bab9a83d2cd93e62ed005a2c1d4f89ae75c67251'
>> |
>> | During handling of the above exception, another exception occurred:
>> |
>> | Traceback (most recent call last):
>> |   File 
>> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/bin/g-ir-scanner",
>>  line 99, in 
>> | sys.exit(scanner_main(sys.argv))
>> |   File 
>> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/scannermain.py",
>>  line 590, in scanner_main
>> | transformer = create_transformer(namespace, options)
>> |   File 
>> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/scannermain.py",
>>  line 409, in create_transformer
>> | transformer.register_include(include_obj)
>> |   File 
>> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/transformer.py",
>>  line 140, in register_include
>> | self._parse_include(filename)
>> |   File 
>> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/transformer.py",
>>  line 230, in _parse_include
>> | self._parse_include(dep_filename)
>> |   File 
>> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/transformer.py",
>>  line 225, in _parse_include
>> | self._cachestore.store(filename, parser)
>> |   File 
>> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/cachestore.py",
>>  line 153, in store
>> | shutil.move(tmp_filename, store_filename)
>> |   File 
>> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
>>  line 833, in move
>> | copy_function(src, real_dst)
>> |   File 
>> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
>>  line 435, in copy2
>> | copystat(src, dst, follow_symlinks=follow_symlinks)
>> |   File 
>> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
>>  line 374, in copystat
>> | lookup("utime")(dst, ns=(st.st_atime_ns, st.st_mtime_ns),
>> | FileNotFoundError: [Errno 2] No such file or directory
>>
>> A similar issue is described in a fix for gobject-introspection-native.
>>
>> https://github.com/openembedded/openembedded-core/commit/d3c48ff7d19e86b2338b1778f9563969bba3d336
>>
>> The problem was fixed there by setting the environment variable
>> GI_SCANNER_DISABLE_CACHE to disable the use of $HOME/.cache.
>>
>> Extend the fix to users of gobject-instropection by promoting the fix
>> to the bbclass.
>>
>> Signed-off-by: Tom Hochstein 
>> Signed-off-by: Alexandre Belloni 
>> (cherry picked from commit 35d5f707f6bb2ce5e9ab908e66e1ea9eeac754b1)
>> Signed-off-by: Steve Sakoman 
>> ---
>>  meta/classes/gobject-introspection-data.bbclass  | 5 +
>>  .../gobject-introspection/gobject-introspection_1.72.0.bb| 3 ---
>>  2 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/classes/gobject-introspection-data.bbclass 
>> b/meta/classes/gobject-introspection-data.bbclass
>> index 2ef684626a..d90cdb4839

Re: [OE-core][kirkstone 13/15] gobject-introspection-data: Disable cache for g-ir-scanner

2022-07-28 Thread Chuck Wolber 
FWIW, the gobject-introspection-native recipe was one of the "canaries in
the mine" that reliably caused an image build to die while I was actively
encountering this GCC10 compiler issue in Hardknott:

https://www.mail-archive.com/yocto@lists.yoctoproject.org/msg06163.html
https://lists.yoctoproject.org/g/yocto/message/53971

Upon re-reading my post, I regret that I did not mention this fact. The
production image recipe I was working on at the time did not happen to
involve gobject-introspection-native, so I overlooked it. Our other image
recipes *DID* invoke gobject-introspection-native, but those were not as
immediately important at the time, and I was trying to keep the problem
description as focused as possible.

I do not expect this reply to result in anything materially relevant to the
problem (it still exists, but we use buildtools to get around it) other
than to add more data that may be relevant to someone googling something
similar in the future.

..Ch:W..

On Tue, Jul 26, 2022 at 5:41 PM Steve Sakoman  wrote:

> From: Tom Hochstein 
>
> An intermittent failure occurs in libical-native do_compile:
>
> | Traceback (most recent call last):
> |   File
> "/.../build/tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
> line 813, in move
> | os.rename(src, real_dst)
> | OSError: [Errno 18] Invalid cross-device link:
> '/tmp/g-ir-scanner-cache-adxo_2bq' ->
> '/home/bamboo/.cache/g-ir-scanner/bab9a83d2cd93e62ed005a2c1d4f89ae75c67251'
> |
> | During handling of the above exception, another exception occurred:
> |
> | Traceback (most recent call last):
> |   File
> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/bin/g-ir-scanner",
> line 99, in 
> | sys.exit(scanner_main(sys.argv))
> |   File
> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/scannermain.py",
> line 590, in scanner_main
> | transformer = create_transformer(namespace, options)
> |   File
> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/scannermain.py",
> line 409, in create_transformer
> | transformer.register_include(include_obj)
> |   File
> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/transformer.py",
> line 140, in register_include
> | self._parse_include(filename)
> |   File
> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/transformer.py",
> line 230, in _parse_include
> | self._parse_include(dep_filename)
> |   File
> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/transformer.py",
> line 225, in _parse_include
> | self._cachestore.store(filename, parser)
> |   File
> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/gobject-introspection/giscanner/cachestore.py",
> line 153, in store
> | shutil.move(tmp_filename, store_filename)
> |   File
> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
> line 833, in move
> | copy_function(src, real_dst)
> |   File
> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
> line 435, in copy2
> | copystat(src, dst, follow_symlinks=follow_symlinks)
> |   File
> "/.../tmp/work/x86_64-linux/libical-native/3.0.14-r0/recipe-sysroot-native/usr/lib/python3.10/shutil.py",
> line 374, in copystat
> | lookup("utime")(dst, ns=(st.st_atime_ns, st.st_mtime_ns),
> | FileNotFoundError: [Errno 2] No such file or directory
>
> A similar issue is described in a fix for gobject-introspection-native.
>
>
> https://github.com/openembedded/openembedded-core/commit/d3c48ff7d19e86b2338b1778f9563969bba3d336
>
> The problem was fixed there by setting the environment variable
> GI_SCANNER_DISABLE_CACHE to disable the use of $HOME/.cache.
>
> Extend the fix to users of gobject-instropection by promoting the fix
> to the bbclass.
>
> Signed-off-by: Tom Hochstein 
> Signed-off-by: Alexandre Belloni 
> (cherry picked from commit 35d5f707f6bb2ce5e9ab908e66e1ea9eeac754b1)
> Signed-off-by: Steve Sakoman 
> ---
>  meta/classes/gobject-introspection-data.bbclass  | 5 +
>  .../gobject-introspection/gobject-introspection_1.72.0.bb| 3 ---
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/meta/classes/gobject-introspection-data.bbclass
> b/meta/classes/gobject-introspection-data.bbclass
> index 2ef684626a..d90cdb4839 100644
> --- a/meta/classes/gobject-introspection-data.bbclass
> +++ b/meta/classes/gobject-introspection-data.bbclass
> @@ -5,3 +5,8 @@
>  # so that qemu use can be avoided when necessary.
>  GI_DATA_ENABLED ?= "${@bb.utils.contains('DISTRO_FEATURES',
>

Re: [OE-core] [meta-oe][PATCH] wic/direct.py: ignore root mountpoint in fstab updater

2022-07-28 Thread Ross Burton 
Added Tobias to distribution list as this is about a patch he sent.

On 27 Jul 2022, at 18:04, Markus Volk via lists.openembedded.org 
 wrote:
> 
> But looking at the commit that introduced the problem, I see that it 
> completely undoes it.
> In general, I like the idea of having the fstab_updater create the root 
> entry, but for this to work without duplication, the /dev/root entry would 
> have to be removed from fstab.
> This would force any wic image to use the fstab_updater (which can also be 
> disabled) and would otherwise result in an fstab file with no root entry.
> Probably removing the /dev/root entry would also break the boot of images 
> that do not use wic

Tobias, looks like we’ve found a problem with your wic patch from May:

https://git.openembedded.org/openembedded-core/commit/?h=20d43a2599d7622b96e2fb0da87a886da1a3794a

Specifically, this bug:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14865

It’s looking like the easiest fix here is to revert your patch, so at least we 
don’t have warnings and unexpected behaviour on boot.  Unless you’re willing to 
rework your patch so that it allows edits to the root mount point but doesn’t 
end up creating duplicates?

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

[OE-core] Hash Equivalency Server

2022-07-28 Thread Jate Sujjavanich 
I would like to use the read-only hashserv with a dunfell build. To test, I
created one based on kirkstone and built the dunfell image using that
hashserv creating a new sstate-cache.

Then, I created a read-only hashserv which used the database of that first
hashserv instance. I started a new build which used the read-only hashserv
and sstate-cache as a PREMIRROR. It required a rebuild of several packages,
and the build printed out warnings like the following:

WARNING: initscripts-1.0-r155 do_populate_lic: Error contacting Hash
Equivalence Server 127.0.0.1:18686: Connection closed
WARNING: initscripts-1.0-r155 do_deploy_source_date_epoch: Error contacting
Hash Equivalence Server 127.0.0.1:18686: Connection closed

The read-only hashserv reports messages like the following:

Unrecognized command {'report': {'taskhash':
'4c79c264282b9bbe444bf9da101e889187a38287711ad09995279b10d19a52a1',
'method': 'oe.sstatesig.OEOuthashBasic', 'outhash':
'be486a087ff983999e0db3e5b4d8b1657b4c849d44202a2abf5d32e9a6ade11a',
'unihash':
'4c79c264282b9bbe444bf9da101e889187a38287711ad09995279b10d19a52a1'}}

Is this how I should do it? After reviewing the hashserv code, I think my
dunfell hashserv client might not handle a read-only hashserver properly,
so it prints those warnings. Do you agree?


Thanks,
Jate S.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168610): 
https://lists.openembedded.org/g/openembedded-core/message/168610
Mute This Topic: https://lists.openembedded.org/mt/92673675/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] create-spdx: Runs the do_create_spdx task after the do_package_write_*

2022-07-28 Thread Jose Quaresma 
Jose Quaresma via lists.openembedded.org  escreveu no dia quinta, 28/07/2022 à(s)
12:46:

>
>
> Richard Purdie  escreveu no dia
> quinta, 28/07/2022 à(s) 12:01:
>
>> On Thu, 2022-07-28 at 09:54 +0100, Jose Quaresma wrote:
>> > Otherwise spdx can have references for data that is not packed.
>> > in the package delivered.
>> >
>> > During do_package_write_ipk task in do_package_ipk some files
>> > is cleaned up from packages-split directory in the funcion
>> > cleanupcontrol.
>> >
>> > This also fixes the following race condictions when the do_create_spdx
>> > task runs the add_package_files function and these files is been deleted
>> > at same time in the task do_package_write_ipk:
>> >
>> > ERROR: alsa-topology-conf-1.2.5.1-r0 do_create_spdx: Error executing a
>> python function in exec_func_python() autogenerated:
>> >
>> > The stack trace of python calls that resulted in this exception/failure
>> was:
>> > File: 'exec_func_python() autogenerated', lineno: 2, function: 
>> >  0001:
>> >  *** 0002:do_create_spdx(d)
>> >  0003:
>> > File:
>> '/srv/oe/build/conf/../../layers/openembedded-core/meta/classes/create-spdx.bbclass',
>> lineno: 567, function: do_create_spdx
>> >  0563:package_doc.add_relationship(package_doc,
>> "DESCRIBES", spdx_package)
>> >  0564:
>> >  0565:package_archive = deploy_dir_spdx / "packages" / (
>> package_doc.name + ".tar.zst")
>> >  0566:with optional_tarfile(package_archive,
>> archive_packaged) as archive:
>> >  *** 0567:package_files = add_package_files(
>> >  0568:d,
>> >  0569:package_doc,
>> >  0570:spdx_package,
>> >  0571:pkgdest / package,
>> > File:
>> '/srv/oe/build/conf/../../layers/openembedded-core/meta/classes/create-spdx.bbclass',
>> lineno: 234, function: add_package_files
>> >  0230:info.mtime = source_date_epoch
>> >  0231:
>> >  0232:archive.addfile(info, f)
>> >  0233:
>> >  *** 0234:sha1 = bb.utils.sha1_file(filepath)
>> >  0235:sha1s.append(sha1)
>> >  0236:
>> spdx_file.checksums.append(oe.spdx.SPDXChecksum(
>> >  0237:algorithm="SHA1",
>> >  0238:checksumValue=sha1,
>> > File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 559, function:
>> sha1_file
>> >  0555:"""
>> >  0556:Return the hex string representation of the SHA1 checksum
>> of the filename
>> >  0557:"""
>> >  0558:import hashlib
>> >  *** 0559:return _hasher(hashlib.sha1(), filename)
>> >  0560:
>> >  0561:def sha384_file(filename):
>> >  0562:"""
>> >  0563:Return the hex string representation of the SHA384
>> checksum of the filename
>> > File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 528, function: _hasher
>> >  0524:
>> >  0525:def _hasher(method, filename):
>> >  0526:import mmap
>> >  0527:
>> >  *** 0528:with open(filename, "rb") as f:
>> >  0529:try:
>> >  0530:with mmap.mmap(f.fileno(), 0,
>> access=mmap.ACCESS_READ) as mm:
>> >  0531:for chunk in iter(lambda: mm.read(8192), b''):
>> >  0532:method.update(chunk)
>> > Exception: FileNotFoundError: [Errno 2] No such file or directory:
>> '/srv/oe/build/tmp-lmp/work/all-lmp-linux/alsa-topology-conf/1.2.5.1-r0/packages-split/alsa-topology-conf/CONTROL/control'
>>
>> We have other places where we've had to teach the code to ignore the
>> control files and we'll probably have to do that here (grep for
>> CONTROL).
>>
>
> The snip that delete this files is in cleanupcontrol
> https://git.yoctoproject.org/poky/tree/meta/classes/package_ipk.bbclass#n51
>
> So these files are not shipped in the ipk package produced.
>

What I mean is those files are not part of the content deployed and it is a
requirement of the packing
standard used so tracking it the sbom doesn't make much sense imo.

ar -xv deploy/ipk/all/alsa-topology-conf_1.2.5.1-r0_all.ipk
x - debian-binary
x - control.tar.gz
x - data.tar.xz

For and deb and ipk we have in deb_write_pkg and ipk_write_pkg:

finally:
cleanupcontrol(root)
bb.utils.unlockfile(lf)

For rpm we have in do_package_rpm:

# rpm 4 creates various empty directories in _topdir, let's clean
them up
cleanupcmd = "rm -rf %s/BUILDROOT %s/SOURCES %s/SPECS %s/SRPMS" %
(workdir, workdir, workdir, workdir)

So all of them delete this package control content at the end but as
do_create_spdx
runs at the same time it can see and track this content as well.

Thanks,
Jose

It breaks the do_create_spdx because it runs after the do_package
> and the same happens for do_package_write_ipk so the two tasks
> can run at the same time.
>
>
>> Ideally we'd fix opkg (and maybe dpkg) to allow creation of packages
>> with

[OE-core] [PATCH 1/2] libarchive: Avoid mount.h conflict between kernel and glibc

2022-07-28 Thread Khem Raj 
glibc 2.36 implements fsconfig_command but it now conflicts with kernel
mount.h and there is no workaround, code in apps have to be adjusted to
use correct API see [1]

[1] https://sourceware.org/glibc/wiki/Release/2.36

Signed-off-by: Khem Raj 
---
 ...t-include-sys-mount.h-when-linux-fs..patch | 47 +++
 .../libarchive/libarchive_3.6.1.bb|  4 +-
 2 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/0001-libarchive-Do-not-include-sys-mount.h-when-linux-fs..patch

diff --git 
a/meta/recipes-extended/libarchive/libarchive/0001-libarchive-Do-not-include-sys-mount.h-when-linux-fs..patch
 
b/meta/recipes-extended/libarchive/libarchive/0001-libarchive-Do-not-include-sys-mount.h-when-linux-fs..patch
new file mode 100644
index 000..0d217996826
--- /dev/null
+++ 
b/meta/recipes-extended/libarchive/libarchive/0001-libarchive-Do-not-include-sys-mount.h-when-linux-fs..patch
@@ -0,0 +1,47 @@
+From a2f68263a1da5ad227bcb9cd8fa91b93c8b6c99f Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Mon, 25 Jul 2022 10:56:53 -0700
+Subject: [PATCH] libarchive: Do not include sys/mount.h when linux/fs.h is
+ present
+
+These headers are in conflict and only one is needed by
+archive_read_disk_posix.c therefore include linux/fs.h if it exists
+otherwise include sys/mount.h
+
+It also helps compiling with glibc 2.36
+where sys/mount.h conflicts with linux/mount.h see [1]
+
+[1] https://sourceware.org/glibc/wiki/Release/2.36
+
+Upstream-Status: Submitted [https://github.com/libarchive/libarchive/pull/1761]
+Signed-off-by: Khem Raj 
+---
+ libarchive/archive_read_disk_posix.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/libarchive/archive_read_disk_posix.c 
b/libarchive/archive_read_disk_posix.c
+index 2b39e672..a96008db 100644
+--- a/libarchive/archive_read_disk_posix.c
 b/libarchive/archive_read_disk_posix.c
+@@ -34,9 +34,6 @@ __FBSDID("$FreeBSD$");
+ #ifdef HAVE_SYS_PARAM_H
+ #include 
+ #endif
+-#ifdef HAVE_SYS_MOUNT_H
+-#include 
+-#endif
+ #ifdef HAVE_SYS_STAT_H
+ #include 
+ #endif
+@@ -54,6 +51,8 @@ __FBSDID("$FreeBSD$");
+ #endif
+ #ifdef HAVE_LINUX_FS_H
+ #include 
++#elif HAVE_SYS_MOUNT_H
++#include 
+ #endif
+ /*
+  * Some Linux distributions have both linux/ext2_fs.h and ext2fs/ext2_fs.h.
+-- 
+2.25.1
+
diff --git a/meta/recipes-extended/libarchive/libarchive_3.6.1.bb 
b/meta/recipes-extended/libarchive/libarchive_3.6.1.bb
index 761cfca6473..24d7918bf9d 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.6.1.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.6.1.bb
@@ -32,7 +32,9 @@ PACKAGECONFIG[zstd] = "--with-zstd,--without-zstd,zstd,"
 
 EXTRA_OECONF += "--enable-largefile"
 
-SRC_URI = "http://libarchive.org/downloads/libarchive-${PV}.tar.gz;
+SRC_URI = "http://libarchive.org/downloads/libarchive-${PV}.tar.gz \
+   
file://0001-libarchive-Do-not-include-sys-mount.h-when-linux-fs..patch \
+   "
 UPSTREAM_CHECK_URI = "http://libarchive.org/;
 
 SRC_URI[sha256sum] = 
"c676146577d989189940f1959d9e3980d28513d74eedfbc6b7f15ea45fe54ee2"
-- 
2.37.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168607): 
https://lists.openembedded.org/g/openembedded-core/message/168607
Mute This Topic: https://lists.openembedded.org/mt/92671306/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 2/2] btrfs-tools: Use linux/mount.h instead of sys/mount.h

2022-07-28 Thread Khem Raj 
This fixes the conflict thats with mount.h from glibc 2.36+ and kernel
[1]

[1] https://sourceware.org/glibc/wiki/Release/2.36

Signed-off-by: Khem Raj 
---
 ...se-linux-mount.h-instead-of-sys-moun.patch | 32 +++
 .../btrfs-tools/btrfs-tools_5.18.1.bb |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 
meta/recipes-devtools/btrfs-tools/btrfs-tools/0001-device-utils.c-Use-linux-mount.h-instead-of-sys-moun.patch

diff --git 
a/meta/recipes-devtools/btrfs-tools/btrfs-tools/0001-device-utils.c-Use-linux-mount.h-instead-of-sys-moun.patch
 
b/meta/recipes-devtools/btrfs-tools/btrfs-tools/0001-device-utils.c-Use-linux-mount.h-instead-of-sys-moun.patch
new file mode 100644
index 000..1397e50b30b
--- /dev/null
+++ 
b/meta/recipes-devtools/btrfs-tools/btrfs-tools/0001-device-utils.c-Use-linux-mount.h-instead-of-sys-moun.patch
@@ -0,0 +1,32 @@
+From d9f118a3408a8a2530f0f60e8072f4323911530f Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Wed, 27 Jul 2022 01:08:20 +
+Subject: [PATCH] device-utils.c: Use linux mount.h instead of sys/mount.h
+
+This file includes linucx/fs.h which includes linux/mount.h and with
+glibc 2.36 linux/mount.h and glibc mount.h are not compatible [1]
+therefore try to avoid including both headers
+
+[1] https://sourceware.org/glibc/wiki/Release/2.36
+
+Upstream-Status: Submitted 
[https://www.spinics.net/lists/linux-btrfs/msg126918.html]
+Signed-off-by: Khem Raj 
+---
+ common/device-utils.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/common/device-utils.c b/common/device-utils.c
+index 617b6746..25a4fb8c 100644
+--- a/common/device-utils.c
 b/common/device-utils.c
+@@ -15,7 +15,6 @@
+  */
+ 
+ #include 
+-#include 
+ #include 
+ #include 
+ #include 
+-- 
+2.25.1
+
diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.18.1.bb 
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.18.1.bb
index 816fc17ae16..5b24bef5cda 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.18.1.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.18.1.bb
@@ -17,6 +17,7 @@ DEPENDS = "util-linux zlib"
 
 SRC_URI = 
"git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git;branch=master
 \

file://0001-Add-a-possibility-to-specify-where-python-modules-ar.patch \
+   
file://0001-device-utils.c-Use-linux-mount.h-instead-of-sys-moun.patch \
"
 SRCREV = "47b5cf867fc37411ef51eb5c09893a95f7f6c3b7"
 S = "${WORKDIR}/git"
-- 
2.37.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168608): 
https://lists.openembedded.org/g/openembedded-core/message/168608
Mute This Topic: https://lists.openembedded.org/mt/92671308/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] [PATCHv2]] recipes-support: rng-tools change systemd service name

2022-07-28 Thread Richard Purdie 
On Thu, 2022-07-28 at 08:34 -0500, Anibal Limón wrote:
> 
> 
> On Wed, Jul 27, 2022 at 11:03 PM Khem Raj  wrote:
> > 
> > 
> > On 7/27/22 10:51 AM, An?bal Lim?n wrote:
> > > 
> > > 
> > > On Wed, Jul 27, 2022 at 5:44 AM Luca Ceresoli
> > >  > > > wrote:
> > > 
> > >      Hello Aníbal,
> > > 
> > >      On Tue, 26 Jul 2022 14:33:22 -0500
> > >      "An?bal Lim?n"  > >      > wrote:
> > > 
> > >       > From: Aníbal Limón  > >      >
> > >       >
> > >       > Change systemd service name from rngd -> rng-tools to
> > > avoid load
> > >      twice
> > >       > the service when sysvinit compatibility is enabled,
> > >       >
> > >       > ...
> > >       > root@:~# ps  | grep rng
> > >       >    23 root         0 SW   [hwrng]
> > >       > 13109 root      3528 R    /usr/sbin/rngd -f -r /dev/hwrng
> > >       > 13117 root      2348 S    grep rng
> > >       > 29418 root     12756 S    /usr/sbin/rngd -r /dev/hwrng
> > >       > ...
> > >       >
> > >       > Signed-off-by: Aníbal Limón  > >      >
> > >       > ---
> > >       >  .../rng-tools/{rngd.service => rng-tools.service}    | 
> > > 0
> > >       >  meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > >           | 12 ++--
> > >       >  2 files changed, 6 insertions(+), 6 deletions(-)
> > >       >  rename meta/recipes-support/rng-tools/rng-
> > > tools/{rngd.service =>
> > >      rng-tools.service} (100%)
> > >       >
> > >       > diff --git
> > >      a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> > >      b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > >       > similarity index 100%
> > >       > rename from meta/recipes-support/rng-tools/rng-
> > > tools/rngd.service
> > >       > rename to meta/recipes-support/rng-tools/rng-tools/rng-
> > > tools.service
> > >       > diff --git a/meta/recipes-support/rng-tools/rng-
> > > tools_6.15.bb
> > >      
> > >      b/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > >      
> > >       > index 0696351903..efc08b5e0a 100644
> > >       > --- a/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > >      
> > >       > +++ b/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > >      
> > >       > @@ -11,7 +11,7 @@ DEPENDS = "sysfsutils openssl"
> > >       >  SRC_URI =
> > >      "git://github.com/nhorman/rng-
> > > tools.git;branch=master;protocol=https
> > >    
> > >   > > https> \
> > >       >             file://init \
> > >       >             file://default \
> > >       > -           file://rngd.service \
> > >       > +           file://rng-tools.service \
> > > 
> > >      This feels strange to me: "rng-tools" does not look like a
> > > daemon name,
> > >      but rather a, well, tools name. Maybe "rng-daemon" would
> > > clarify?
> > > 
> > > 
> > > Another option is to change the init daemon to be called rngd.
> > 
> > I think yet another way is to check for condition when sysvinit 
> > compatibility is enabled during install time and decide if we need
> > to 
> > install both sysvinit script and systemd service or not. I do not
> > think
> > renaming .service file is a good solution here.
> > 
> 
> 
> I have that solution on the first version of this patch,
> 
> https://lists.openembedded.org/g/openembedded-core/message/167841?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Crng-tools%2C20%2C2%2C0%2C92278770

I took the v2 as I think it is the less invasive solution.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168606): 
https://lists.openembedded.org/g/openembedded-core/message/168606
Mute This Topic: https://lists.openembedded.org/mt/92635255/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] [PATCHv2]] recipes-support: rng-tools change systemd service name

2022-07-28 Thread An?bal Lim?n 
On Wed, Jul 27, 2022 at 11:03 PM Khem Raj  wrote:

>
>
> On 7/27/22 10:51 AM, An?bal Lim?n wrote:
> >
> >
> > On Wed, Jul 27, 2022 at 5:44 AM Luca Ceresoli  > > wrote:
> >
> > Hello Aníbal,
> >
> > On Tue, 26 Jul 2022 14:33:22 -0500
> > "An?bal Lim?n"  > > wrote:
> >
> >  > From: Aníbal Limón  > >
> >  >
> >  > Change systemd service name from rngd -> rng-tools to avoid load
> > twice
> >  > the service when sysvinit compatibility is enabled,
> >  >
> >  > ...
> >  > root@:~# ps  | grep rng
> >  >23 root 0 SW   [hwrng]
> >  > 13109 root  3528 R/usr/sbin/rngd -f -r /dev/hwrng
> >  > 13117 root  2348 Sgrep rng
> >  > 29418 root 12756 S/usr/sbin/rngd -r /dev/hwrng
> >  > ...
> >  >
> >  > Signed-off-by: Aníbal Limón  > >
> >  > ---
> >  >  .../rng-tools/{rngd.service => rng-tools.service}|  0
> >  >  meta/recipes-support/rng-tools/rng-tools_6.15.bb
> >  | 12 ++--
> >  >  2 files changed, 6 insertions(+), 6 deletions(-)
> >  >  rename meta/recipes-support/rng-tools/rng-tools/{rngd.service =>
> > rng-tools.service} (100%)
> >  >
> >  > diff --git
> > a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> > b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> >  > similarity index 100%
> >  > rename from meta/recipes-support/rng-tools/rng-tools/rngd.service
> >  > rename to
> meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> >  > diff --git a/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > 
> > b/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > 
> >  > index 0696351903..efc08b5e0a 100644
> >  > --- a/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > 
> >  > +++ b/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > 
> >  > @@ -11,7 +11,7 @@ DEPENDS = "sysfsutils openssl"
> >  >  SRC_URI =
> > "git://github.com/nhorman/rng-tools.git;branch=master;protocol=https
> > <
> http://github.com/nhorman/rng-tools.git;branch=master;protocol=https> \
> >  > file://init \
> >  > file://default \
> >  > -   file://rngd.service \
> >  > +   file://rng-tools.service \
> >
> > This feels strange to me: "rng-tools" does not look like a daemon
> name,
> > but rather a, well, tools name. Maybe "rng-daemon" would clarify?
> >
> >
> > Another option is to change the init daemon to be called rngd.
>
> I think yet another way is to check for condition when sysvinit
> compatibility is enabled during install time and decide if we need to
> install both sysvinit script and systemd service or not. I do not think
> renaming .service file is a good solution here.
>

I have that solution on the first version of this patch,

https://lists.openembedded.org/g/openembedded-core/message/167841?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Crng-tools%2C20%2C2%2C0%2C92278770

Regards,
Anibal


>
> >
> > Regards,
> > Anibal
> >
> >
> > Still I'm taking this patch for testing, I'll replace it with v2
> should
> > you send one.
> >
> > However please note there is an extra ']' in the subject: [PATCHv2]]
> > should be [PATCHv2]. This leads 'git am' to produce a commit starting
> > with a "] " prefix. I fixed it while applying, however you should
> check
> > that in the future.
> >
> > Best regards.
> > --
> > Luca Ceresoli, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com 
> >
> >
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168605): 
https://lists.openembedded.org/g/openembedded-core/message/168605
Mute This Topic: https://lists.openembedded.org/mt/92635255/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] create-spdx: Fix supplier field

2022-07-28 Thread Joshua Watt 


On 7/27/22 12:09, Mihai Lindner wrote:

The correct field name is "supplier" according to SPDX schema.
The "supplier" field translates to "PackageSupplier", but that's for
tag-value format.


LGTM, Thanks.


Reviewed-by: Joshua Watt 



Signed-off-by: Mihai Lindner 
---
  meta/classes/create-spdx.bbclass | 6 +++---
  meta/lib/oe/spdx.py  | 2 +-
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index 15cccac84b..21cd5be3cb 100644
--- a/meta/classes/create-spdx.bbclass
+++ b/meta/classes/create-spdx.bbclass
@@ -451,7 +451,7 @@ python do_create_spdx() {
  recipe.name = d.getVar("PN")
  recipe.versionInfo = d.getVar("PV")
  recipe.SPDXID = oe.sbom.get_recipe_spdxid(d)
-recipe.packageSupplier = d.getVar("SPDX_SUPPLIER")
+recipe.supplier = d.getVar("SPDX_SUPPLIER")
  if bb.data.inherits_class("native", d) or bb.data.inherits_class("cross", 
d):
  recipe.annotations.append(create_annotation(d, "isNative"))
  
@@ -561,7 +561,7 @@ python do_create_spdx() {

  spdx_package.name = pkg_name
  spdx_package.versionInfo = d.getVar("PV")
  spdx_package.licenseDeclared = 
convert_license_to_spdx(package_license, package_doc, d, found_licenses)
-spdx_package.packageSupplier = d.getVar("SPDX_SUPPLIER")
+spdx_package.supplier = d.getVar("SPDX_SUPPLIER")
  
  package_doc.packages.append(spdx_package)
  
@@ -901,7 +901,7 @@ def combine_spdx(d, rootfs_name, rootfs_deploydir, rootfs_spdxid, packages):

  image.name = d.getVar("PN")
  image.versionInfo = d.getVar("PV")
  image.SPDXID = rootfs_spdxid
-image.packageSupplier = d.getVar("SPDX_SUPPLIER")
+image.supplier = d.getVar("SPDX_SUPPLIER")
  
  doc.packages.append(image)
  
diff --git a/meta/lib/oe/spdx.py b/meta/lib/oe/spdx.py

index 14ca706895..6d56ed90df 100644
--- a/meta/lib/oe/spdx.py
+++ b/meta/lib/oe/spdx.py
@@ -218,7 +218,7 @@ class SPDXPackage(SPDXObject):
  SPDXID = _String()
  versionInfo = _String()
  downloadLocation = _String(default="NOASSERTION")
-packageSupplier = _String(default="NOASSERTION")
+supplier = _String(default="NOASSERTION")
  homepage = _String()
  licenseConcluded = _String(default="NOASSERTION")
  licenseDeclared = _String(default="NOASSERTION")

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168604): 
https://lists.openembedded.org/g/openembedded-core/message/168604
Mute This Topic: https://lists.openembedded.org/mt/92653678/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] create-spdx: Runs the do_create_spdx task after the do_package_write_*

2022-07-28 Thread Jose Quaresma 
Richard Purdie  escreveu no dia quinta,
28/07/2022 à(s) 12:01:

> On Thu, 2022-07-28 at 09:54 +0100, Jose Quaresma wrote:
> > Otherwise spdx can have references for data that is not packed.
> > in the package delivered.
> >
> > During do_package_write_ipk task in do_package_ipk some files
> > is cleaned up from packages-split directory in the funcion
> > cleanupcontrol.
> >
> > This also fixes the following race condictions when the do_create_spdx
> > task runs the add_package_files function and these files is been deleted
> > at same time in the task do_package_write_ipk:
> >
> > ERROR: alsa-topology-conf-1.2.5.1-r0 do_create_spdx: Error executing a
> python function in exec_func_python() autogenerated:
> >
> > The stack trace of python calls that resulted in this exception/failure
> was:
> > File: 'exec_func_python() autogenerated', lineno: 2, function: 
> >  0001:
> >  *** 0002:do_create_spdx(d)
> >  0003:
> > File:
> '/srv/oe/build/conf/../../layers/openembedded-core/meta/classes/create-spdx.bbclass',
> lineno: 567, function: do_create_spdx
> >  0563:package_doc.add_relationship(package_doc,
> "DESCRIBES", spdx_package)
> >  0564:
> >  0565:package_archive = deploy_dir_spdx / "packages" / (
> package_doc.name + ".tar.zst")
> >  0566:with optional_tarfile(package_archive,
> archive_packaged) as archive:
> >  *** 0567:package_files = add_package_files(
> >  0568:d,
> >  0569:package_doc,
> >  0570:spdx_package,
> >  0571:pkgdest / package,
> > File:
> '/srv/oe/build/conf/../../layers/openembedded-core/meta/classes/create-spdx.bbclass',
> lineno: 234, function: add_package_files
> >  0230:info.mtime = source_date_epoch
> >  0231:
> >  0232:archive.addfile(info, f)
> >  0233:
> >  *** 0234:sha1 = bb.utils.sha1_file(filepath)
> >  0235:sha1s.append(sha1)
> >  0236:
> spdx_file.checksums.append(oe.spdx.SPDXChecksum(
> >  0237:algorithm="SHA1",
> >  0238:checksumValue=sha1,
> > File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 559, function: sha1_file
> >  0555:"""
> >  0556:Return the hex string representation of the SHA1 checksum
> of the filename
> >  0557:"""
> >  0558:import hashlib
> >  *** 0559:return _hasher(hashlib.sha1(), filename)
> >  0560:
> >  0561:def sha384_file(filename):
> >  0562:"""
> >  0563:Return the hex string representation of the SHA384
> checksum of the filename
> > File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 528, function: _hasher
> >  0524:
> >  0525:def _hasher(method, filename):
> >  0526:import mmap
> >  0527:
> >  *** 0528:with open(filename, "rb") as f:
> >  0529:try:
> >  0530:with mmap.mmap(f.fileno(), 0,
> access=mmap.ACCESS_READ) as mm:
> >  0531:for chunk in iter(lambda: mm.read(8192), b''):
> >  0532:method.update(chunk)
> > Exception: FileNotFoundError: [Errno 2] No such file or directory:
> '/srv/oe/build/tmp-lmp/work/all-lmp-linux/alsa-topology-conf/1.2.5.1-r0/packages-split/alsa-topology-conf/CONTROL/control'
>
> We have other places where we've had to teach the code to ignore the
> control files and we'll probably have to do that here (grep for
> CONTROL).
>

The snip that delete this files is in cleanupcontrol
https://git.yoctoproject.org/poky/tree/meta/classes/package_ipk.bbclass#n51

So these files are not shipped in the ipk package produced.
It breaks the do_create_spdx because it runs after the do_package
and the same happens for do_package_write_ipk so the two tasks
can run at the same time.


> Ideally we'd fix opkg (and maybe dpkg) to allow creation of packages
> with the files placed externally.
>

I think I didn't quite understand this part, can you please explain it a
bit more?


>
> I have also wondered if we should create a specific hardlinked tree to
> handle this but that does come at an IO cost.
>
> I don't really want to add a dependency constraint like this for
> something we already handle differently elsewhere though.
>

yeah, It's a bit ugly because it adds some tasks that don't even run (all
types of packages
in this case). Since I don't know what package types are chosen by the
user, I added all of them.

Jose


>
> Cheers,
>
> Richard
>


-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168603): 
https://lists.openembedded.org/g/openembedded-core/message/168603
Mute This Topic: https://lists.openembedded.org/mt/9227/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub

[OE-core] [RFC][PATCH] bitbake.conf: change TOOLCHAIN_OPTIONS not to start with space

2022-07-28 Thread Martin Jansa 
* it was introduced this way in 2007:
  
https://git.openembedded.org/openembedded-core/commit/?id=0138501213f140198abdead3ffa6b3ba80462c98
  but now there are quite a few places which use it after a space (which 
doesn't hurt):
  meta/classes/cmake.bbclass:OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} 
${TOOLCHAIN_OPTIONS} ${CFLAGS}"
  meta/classes/cmake.bbclass:OECMAKE_CXX_FLAGS ?= "${HOST_CC_ARCH} 
${TOOLCHAIN_OPTIONS} ${CXXFLAGS}"
  meta/classes/cmake.bbclass:OECMAKE_C_LINK_FLAGS ?= "${HOST_CC_ARCH} 
${TOOLCHAIN_OPTIONS} ${CPPFLAGS} ${LDFLAGS}"
  meta/classes/cmake.bbclass:OECMAKE_CXX_LINK_FLAGS ?= "${HOST_CC_ARCH} 
${TOOLCHAIN_OPTIONS} ${CXXFLAGS} ${LDFLAGS}"
  meta/classes/kernel-yocto.bbclass:  CFLAGS="${CFLAGS} ${TOOLCHAIN_OPTIONS}" 
HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}" 
CC="${KERNEL_CC}" LD="${KERNEL_LD}" ARCH=${ARCH} merge_config.sh -O ${B} 
${config_flags} ${configs} > ${meta_dir}/cfg/merge_config_build.log 2>&1
  meta/recipes-bsp/u-boot/u-boot.inc:EXTRA_OEMAKE = 
'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc ${TOOLCHAIN_OPTIONS}" 
V=1'
  meta/recipes-devtools/diffstat/diffstat_1.64.bb:LDFLAGS += 
"${TOOLCHAIN_OPTIONS}"
  meta/recipes-devtools/go/go-runtime.inc:GO_EXTLDFLAGS ?= "${HOST_CC_ARCH} 
${TOOLCHAIN_OPTIONS} ${LDFLAGS}"
  meta/recipes-extended/wget/wget.inc:EXTRA_OEMAKE += 
'TOOLCHAIN_OPTIONS="${TOOLCHAIN_OPTIONS}" \
  meta/recipes-kernel/linux/linux-yocto.inc:KERNEL_CC:append:aarch64 = " 
${TOOLCHAIN_OPTIONS}"
  meta/recipes-kernel/linux/linux-yocto.inc:KERNEL_LD:append:aarch64 = " 
${TOOLCHAIN_OPTIONS}"
  meta/recipes-kernel/linux/linux-yocto.inc:KERNEL_CC:append:nios2 = " 
${TOOLCHAIN_OPTIONS}"
  meta/recipes-kernel/linux/linux-yocto.inc:KERNEL_LD:append:nios2 = " 
${TOOLCHAIN_OPTIONS}"
  meta/recipes-kernel/linux/linux-yocto.inc:KERNEL_CC:append:arc = " 
${TOOLCHAIN_OPTIONS}"
  meta/recipes-kernel/linux/linux-yocto.inc:KERNEL_LD:append:arc = " 
${TOOLCHAIN_OPTIONS}"

  not using space now seems a bit strange to me (noticed when trying to prepend
  something to TOOLCHAIN_OPTIONS)

* it made more sense when default TOOLCHAIN_OPTIONS were empty, but
  since 2010 it's almost always used to set --sysroot:
  
https://git.openembedded.org/openembedded-core/commit/?id=6124cccddfc202124fa76bb677ad3e06f0fefc70

Signed-off-by: Martin Jansa 
---
 meta/classes/cross-canadian.bbclass|  2 +-
 meta/classes/go.bbclass|  2 +-
 meta/conf/bitbake.conf | 12 ++--
 meta/recipes-devtools/go/go-runtime.inc|  2 +-
 meta/recipes-extended/ltp/ltp_20220527.bb  |  2 +-
 meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb |  2 +-
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/meta/classes/cross-canadian.bbclass 
b/meta/classes/cross-canadian.bbclass
index a0e9d23836..686646357c 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -104,7 +104,7 @@ INHIBIT_DEFAULT_DEPS = "1"
 
 STAGING_DIR_HOST = "${RECIPE_SYSROOT}"
 
-TOOLCHAIN_OPTIONS = " --sysroot=${RECIPE_SYSROOT}"
+TOOLCHAIN_OPTIONS = "--sysroot=${RECIPE_SYSROOT}"
 
 PATH:append = ":${TMPDIR}/sysroots/${HOST_ARCH}/${bindir_cross}"
 PKGHIST_DIR = 
"${TMPDIR}/pkghistory/${HOST_ARCH}-${SDKPKGSUFFIX}${HOST_VENDOR}-${HOST_OS}/"
diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index cd2daed70b..c6b38bd294 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -40,7 +40,7 @@ GO_RPATH_LINK = 
"${@'-Wl,-rpath-link=${STAGING_DIR_TARGET}${libdir}/go/pkg/${TAR
 GO_RPATH = "${@'-r ${libdir}/go/pkg/${TARGET_GOTUPLE}_dynlink' if 
d.getVar('GO_DYNLINK') else ''}"
 GO_RPATH:class-native = "${@'-r 
${STAGING_LIBDIR_NATIVE}/go/pkg/${TARGET_GOTUPLE}_dynlink' if 
d.getVar('GO_DYNLINK') else ''}"
 GO_RPATH_LINK:class-native = 
"${@'-Wl,-rpath-link=${STAGING_LIBDIR_NATIVE}/go/pkg/${TARGET_GOTUPLE}_dynlink' 
if d.getVar('GO_DYNLINK') else ''}"
-GO_EXTLDFLAGS ?= "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} ${GO_RPATH_LINK} 
${LDFLAGS}"
+GO_EXTLDFLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${GO_RPATH_LINK} 
${LDFLAGS}"
 GO_LINKMODE ?= ""
 GO_LINKMODE:class-nativesdk = "--linkmode=external"
 GO_LINKMODE:class-native = "--linkmode=external"
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 1c2ebf333e..27478b1107 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -547,14 +547,14 @@ HOSTTOOLS_NONFATAL += "git-lfs"
 
 CCACHE ??= ""
 
-TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
+TOOLCHAIN_OPTIONS = "--sysroot=${STAGING_DIR_TARGET}"
 
-export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
-export CXX = "${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
-export FC = "${CCACHE}${HOST_PREFIX}gfortran 
${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
-export CPP = "${HOST_PREFIX}gcc -E${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
+export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+export CXX =

[OE-core] [RFC][PATCH] bitbake.conf: introduce LINKER/BUILD_LINKER variables

2022-07-28 Thread Martin Jansa 
* makes it a bit easier to replace ld with ld.bfd or some other implementation
  in LD/BUILD_LD variables without changing this whole variable and without
  depending on ld-is-gold to set ld symlink to preferred implementation (or
  when we want to force different one for specific recipe, e.g. forcing bfd
  where gold fails, like in ltp)

Signed-off-by: Martin Jansa 
---
 meta/conf/bitbake.conf | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 1d36aae8b3..1c2ebf333e 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -553,7 +553,8 @@ export CC = "${CCACHE}${HOST_PREFIX}gcc 
${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
 export CXX = "${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
 export FC = "${CCACHE}${HOST_PREFIX}gfortran 
${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
 export CPP = "${HOST_PREFIX}gcc -E${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
-export LD = "${HOST_PREFIX}ld${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}"
+LINKER = "ld"
+export LD = "${HOST_PREFIX}${LINKER}${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}"
 export CCLD = "${CC}"
 export AR = "${HOST_PREFIX}gcc-ar"
 export AS = "${HOST_PREFIX}as ${HOST_AS_ARCH}"
@@ -570,7 +571,8 @@ export BUILD_CC = "${CCACHE}${BUILD_PREFIX}gcc 
${BUILD_CC_ARCH}"
 export BUILD_CXX = "${CCACHE}${BUILD_PREFIX}g++ ${BUILD_CC_ARCH}"
 export BUILD_FC = "${CCACHE}${BUILD_PREFIX}gfortran ${BUILD_CC_ARCH}"
 export BUILD_CPP = "${BUILD_PREFIX}gcc ${BUILD_CC_ARCH} -E"
-export BUILD_LD = "${BUILD_PREFIX}ld ${BUILD_LD_ARCH}"
+BUILD_LINKER = "ld"
+export BUILD_LD = "${BUILD_PREFIX}${BUILD_LINKER} ${BUILD_LD_ARCH}"
 export BUILD_CCLD = "${BUILD_PREFIX}gcc ${BUILD_CC_ARCH}"
 export BUILD_AR = "${BUILD_PREFIX}ar"
 export BUILD_AS = "${BUILD_PREFIX}as ${BUILD_AS_ARCH}"

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168601): 
https://lists.openembedded.org/g/openembedded-core/message/168601
Mute This Topic: https://lists.openembedded.org/mt/92668261/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] ltp: fix build with ld-is-gold in DISTRO_FEATURES

2022-07-28 Thread Martin Jansa 
* backport one more commit for LD call which conflicts with the
  0001-kvm-use-LD-instead-of-hardcoding-ld.patch we already had
  and replace this 2nd patch with the rebased version which is
  now merged upstream

* then backport additional patch which introduces KVM_LD variable
  which we can set to use .bfd suffix in LD when ld-is-gold is
  in DISTRO_FEATURES to work around gold incompatibility reported:
  https://github.com/linux-test-project/ltp/pull/948#issuecomment-1193138866
  https://lists.openembedded.org/g/openembedded-core/message/168193

  http://errors.yoctoproject.org/Errors/Details/663094/

  x86_64-oe-linux-ld 
--sysroot=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/ltp/20220527-r0/recipe-sysroot
   -z noexecstack -r -T 
/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/ltp/20220527-r0/git/testcases/kernel/kvm/linker/payload.lds
 --oformat=elf64-x86-64 -o kvm_pagefault01-payload.o kvm_pagefault01-payload.bin
  x86_64-oe-linux-ld: error: kvm_pagefault01-payload.bin:1:1: invalid character
  make: *** [Makefile:53: kvm_pagefault01-payload.o] Error 1

Signed-off-by: Martin Jansa 
---
 depends on "ltp: Add post release runtime fixes" change currently in 
master-next:
 
https://git.openembedded.org/openembedded-core/commit/?h=master-next=024ce059a64eb2f96dce2880e5708afd25dd45f2

 ...-access-mode-in-KVM-test-ELF-headers.patch | 40 
 ...kvm-use-LD-instead-of-hardcoding-ld.patch} | 26 
 ...ile-variable-for-building-KVM-payloa.patch | 63 +++
 meta/recipes-extended/ltp/ltp_20220527.bb | 13 +++-
 4 files changed, 128 insertions(+), 14 deletions(-)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-kvm-Fix-stack-access-mode-in-KVM-test-ELF-headers.patch
 rename 
meta/recipes-extended/ltp/ltp/{0001-kvm-use-LD-instead-of-hardcoding-ld.patch 
=> 0002-kvm-use-LD-instead-of-hardcoding-ld.patch} (60%)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0003-Add-KVM_LD-Makefile-variable-for-building-KVM-payloa.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-kvm-Fix-stack-access-mode-in-KVM-test-ELF-headers.patch
 
b/meta/recipes-extended/ltp/ltp/0001-kvm-Fix-stack-access-mode-in-KVM-test-ELF-headers.patch
new file mode 100644
index 00..764e9c0d9f
--- /dev/null
+++ 
b/meta/recipes-extended/ltp/ltp/0001-kvm-Fix-stack-access-mode-in-KVM-test-ELF-headers.patch
@@ -0,0 +1,40 @@
+From 608fc7bcda43e60536ae1f19842f7affba8f0aea Mon Sep 17 00:00:00 2001
+From: Martin Doucha 
+Date: Wed, 1 Jun 2022 16:16:34 +0200
+Subject: [PATCH] kvm: Fix stack access mode in KVM test ELF headers
+
+When the linker converts guest payload binary into a linkable resource
+object file, it somehow defaults to requesting executable stack section
+for the final test binary. This trips some build-time security checks
+on newer systems. Add explicit linker option to make the stack
+non-executable.
+
+Suggested-by: Fabian Vogt 
+Signed-off-by: Martin Doucha 
+Reviewed-by: Petr Vorel 
+Reviewed-by: Cyril Hrubis 
+
+Signed-off-by: Martin Jansa 
+Upstream-Status: Backport 
[https://github.com/linux-test-project/ltp/commit/f9715d7c2e78713e26533c6e0846aaabf5c4095b]
+---
+ testcases/kernel/kvm/Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/testcases/kernel/kvm/Makefile b/testcases/kernel/kvm/Makefile
+index 69a9946fe..adab56952 100644
+--- a/testcases/kernel/kvm/Makefile
 b/testcases/kernel/kvm/Makefile
+@@ -50,11 +50,11 @@ include $(top_srcdir)/include/mk/generic_leaf_target.mk
+ ifdef VERBOSE
+   $(CC) $(GUEST_CPPFLAGS) $(GUEST_CFLAGS) $(GUEST_LDFLAGS) -o 
$*-payload.elf $^ $(GUEST_LDLIBS)
+   objcopy -O binary -j .init.boot -j .text -j .data -j .init -j 
.preinit_array -j .init_array --gap-fill=0 $*-payload.elf $*-payload.bin
+-  ld -r -T $(abs_srcdir)/linker/payload.lds --oformat=$(BIN_FORMAT) -o $@ 
$*-payload.bin
++  ld -z noexecstack -r -T $(abs_srcdir)/linker/payload.lds 
--oformat=$(BIN_FORMAT) -o $@ $*-payload.bin
+ else
+   @$(CC) $(GUEST_CPPFLAGS) $(GUEST_CFLAGS) $(GUEST_LDFLAGS) -o 
$*-payload.elf $^ $(GUEST_LDLIBS)
+   @objcopy -O binary -j .init.boot -j .text -j .data -j .init -j 
.preinit_array -j .init_array --gap-fill=0 $*-payload.elf $*-payload.bin
+-  @ld -r -T $(abs_srcdir)/linker/payload.lds --oformat=$(BIN_FORMAT) -o 
$@ $*-payload.bin
++  @ld -z noexecstack -r -T $(abs_srcdir)/linker/payload.lds 
--oformat=$(BIN_FORMAT) -o $@ $*-payload.bin
+   @echo KVM_CC $(target_rel_dir)$@
+ endif
+   @rm $*-payload.elf $*-payload.bin
diff --git 
a/meta/recipes-extended/ltp/ltp/0001-kvm-use-LD-instead-of-hardcoding-ld.patch 
b/meta/recipes-extended/ltp/ltp/0002-kvm-use-LD-instead-of-hardcoding-ld.patch
similarity index 60%
rename from 
meta/recipes-extended/ltp/ltp/0001-kvm-use-LD-instead-of-hardcoding-ld.patch
rename to 
meta/recipes-extended/ltp/ltp/0002-kvm-use-LD-instead-of-hardcoding-ld.patch
index 23634d0c86..060ba05835 100644
---

Re: [OE-core][PATCH] create-spdx: Runs the do_create_spdx task after the do_package_write_*

2022-07-28 Thread Richard Purdie 
On Thu, 2022-07-28 at 09:54 +0100, Jose Quaresma wrote:
> Otherwise spdx can have references for data that is not packed.
> in the package delivered.
> 
> During do_package_write_ipk task in do_package_ipk some files
> is cleaned up from packages-split directory in the funcion
> cleanupcontrol.
> 
> This also fixes the following race condictions when the do_create_spdx
> task runs the add_package_files function and these files is been deleted
> at same time in the task do_package_write_ipk:
> 
> ERROR: alsa-topology-conf-1.2.5.1-r0 do_create_spdx: Error executing a python 
> function in exec_func_python() autogenerated:
> 
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_func_python() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:do_create_spdx(d)
>  0003:
> File: 
> '/srv/oe/build/conf/../../layers/openembedded-core/meta/classes/create-spdx.bbclass',
>  lineno: 567, function: do_create_spdx
>  0563:package_doc.add_relationship(package_doc, "DESCRIBES", 
> spdx_package)
>  0564:
>  0565:package_archive = deploy_dir_spdx / "packages" / 
> (package_doc.name + ".tar.zst")
>  0566:with optional_tarfile(package_archive, 
> archive_packaged) as archive:
>  *** 0567:package_files = add_package_files(
>  0568:d,
>  0569:package_doc,
>  0570:spdx_package,
>  0571:pkgdest / package,
> File: 
> '/srv/oe/build/conf/../../layers/openembedded-core/meta/classes/create-spdx.bbclass',
>  lineno: 234, function: add_package_files
>  0230:info.mtime = source_date_epoch
>  0231:
>  0232:archive.addfile(info, f)
>  0233:
>  *** 0234:sha1 = bb.utils.sha1_file(filepath)
>  0235:sha1s.append(sha1)
>  0236:spdx_file.checksums.append(oe.spdx.SPDXChecksum(
>  0237:algorithm="SHA1",
>  0238:checksumValue=sha1,
> File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 559, function: sha1_file
>  0555:"""
>  0556:Return the hex string representation of the SHA1 checksum of 
> the filename
>  0557:"""
>  0558:import hashlib
>  *** 0559:return _hasher(hashlib.sha1(), filename)
>  0560:
>  0561:def sha384_file(filename):
>  0562:"""
>  0563:Return the hex string representation of the SHA384 checksum of 
> the filename
> File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 528, function: _hasher
>  0524:
>  0525:def _hasher(method, filename):
>  0526:import mmap
>  0527:
>  *** 0528:with open(filename, "rb") as f:
>  0529:try:
>  0530:with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) 
> as mm:
>  0531:for chunk in iter(lambda: mm.read(8192), b''):
>  0532:method.update(chunk)
> Exception: FileNotFoundError: [Errno 2] No such file or directory: 
> '/srv/oe/build/tmp-lmp/work/all-lmp-linux/alsa-topology-conf/1.2.5.1-r0/packages-split/alsa-topology-conf/CONTROL/control'

We have other places where we've had to teach the code to ignore the
control files and we'll probably have to do that here (grep for
CONTROL).

Ideally we'd fix opkg (and maybe dpkg) to allow creation of packages
with the files placed externally.

I have also wondered if we should create a specific hardlinked tree to
handle this but that does come at an IO cost.

I don't really want to add a dependency constraint like this for
something we already handle differently elsewhere though.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168599): 
https://lists.openembedded.org/g/openembedded-core/message/168599
Mute This Topic: https://lists.openembedded.org/mt/9227/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] gstreamer1.0-plugins-bad: add PACKAGECONFIG for onevpl

2022-07-28 Thread Jose Quaresma 
Hi Naveen,

PACKAGECONFIG[msdk] = "-Dmsdk=enabled,-Dmsdk=disabled,intel-mediasdk"
https://cgit.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.3.bb#n64

The msdk knob is already there so what is missing is the -Dmfx_api that
will change the target dependency.

Jose

Naveen Saini  escreveu no dia quinta,
28/07/2022 à(s) 07:48:

> Please ignore this patch. It needs some re-work !
>
> Regards,
> Naveen
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Naveen Saini
> > Sent: Thursday, July 28, 2022 12:47 PM
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH] gstreamer1.0-plugins-bad: add PACKAGECONFIG
> > for onevpl
> >
> > Allow user to build this plugin against MFX version 2.2+ (oneVPL)
> >
> > https://github.com/GStreamer/gst-plugins-
> > bad/commit/beda9a73339bef878e95798f629a868c647627ce
> >
> > Signed-off-by: Naveen Saini 
> > ---
> >  .../gstreamer/gstreamer1.0-plugins-bad_1.20.3.bb | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-
> > bad_1.20.3.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-
> > bad_1.20.3.bb
> > index 2dd42395f7..6048e17214 100644
> > --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-
> > bad_1.20.3.bb
> > +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-
> > bad_1.20.3.bb
> > @@ -97,6 +97,7 @@ PACKAGECONFIG[webrtcdsp]   = "-
> > Dwebrtcdsp=enabled,-Dwebrtcdsp=disabled,webrt
> >  PACKAGECONFIG[zbar]= "-Dzbar=enabled,-Dzbar=disabled,zbar"
> >  PACKAGECONFIG[x11] = "-Dx11=enabled,-Dx11=disabled,libxcb
> > libxkbcommon"
> >  PACKAGECONFIG[x265]= "-Dx265=enabled,-Dx265=disabled,x265"
> > +PACKAGECONFIG[onevpl]  = "-Dmsdk=enabled -Dmfx_api=oneVPL,-
> > Dmsdk=disabled,onevpl onevpl-intel-gpu"
> >
> >  GSTREAMER_GPL = "${@bb.utils.filter('PACKAGECONFIG', 'faad resindvd
> > x265', d)}"
> >
> > --
> > 2.25.1
>
>
> 
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168598): 
https://lists.openembedded.org/g/openembedded-core/message/168598
Mute This Topic: https://lists.openembedded.org/mt/92664604/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] create-spdx: Runs the do_create_spdx task after the do_package_write_*

2022-07-28 Thread Jose Quaresma 
Otherwise spdx can have references for data that is not packed.
in the package delivered.

During do_package_write_ipk task in do_package_ipk some files
is cleaned up from packages-split directory in the funcion
cleanupcontrol.

This also fixes the following race condictions when the do_create_spdx
task runs the add_package_files function and these files is been deleted
at same time in the task do_package_write_ipk:

ERROR: alsa-topology-conf-1.2.5.1-r0 do_create_spdx: Error executing a python 
function in exec_func_python() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_create_spdx(d)
 0003:
File: 
'/srv/oe/build/conf/../../layers/openembedded-core/meta/classes/create-spdx.bbclass',
 lineno: 567, function: do_create_spdx
 0563:package_doc.add_relationship(package_doc, "DESCRIBES", 
spdx_package)
 0564:
 0565:package_archive = deploy_dir_spdx / "packages" / 
(package_doc.name + ".tar.zst")
 0566:with optional_tarfile(package_archive, archive_packaged) 
as archive:
 *** 0567:package_files = add_package_files(
 0568:d,
 0569:package_doc,
 0570:spdx_package,
 0571:pkgdest / package,
File: 
'/srv/oe/build/conf/../../layers/openembedded-core/meta/classes/create-spdx.bbclass',
 lineno: 234, function: add_package_files
 0230:info.mtime = source_date_epoch
 0231:
 0232:archive.addfile(info, f)
 0233:
 *** 0234:sha1 = bb.utils.sha1_file(filepath)
 0235:sha1s.append(sha1)
 0236:spdx_file.checksums.append(oe.spdx.SPDXChecksum(
 0237:algorithm="SHA1",
 0238:checksumValue=sha1,
File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 559, function: sha1_file
 0555:"""
 0556:Return the hex string representation of the SHA1 checksum of the 
filename
 0557:"""
 0558:import hashlib
 *** 0559:return _hasher(hashlib.sha1(), filename)
 0560:
 0561:def sha384_file(filename):
 0562:"""
 0563:Return the hex string representation of the SHA384 checksum of 
the filename
File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 528, function: _hasher
 0524:
 0525:def _hasher(method, filename):
 0526:import mmap
 0527:
 *** 0528:with open(filename, "rb") as f:
 0529:try:
 0530:with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as 
mm:
 0531:for chunk in iter(lambda: mm.read(8192), b''):
 0532:method.update(chunk)
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'/srv/oe/build/tmp-lmp/work/all-lmp-linux/alsa-topology-conf/1.2.5.1-r0/packages-split/alsa-topology-conf/CONTROL/control'

ERROR: Logfile of failure stored in: 
/srv/oe/build/tmp-lmp/work/all-lmp-linux/alsa-topology-conf/1.2.5.1-r0/temp/log.do_create_spdx.998864
INFO: recipe alsa-topology-conf-1.2.5.1-r0: task do_create_spdx: Failed

Signed-off-by: Jose Quaresma 
---
 meta/classes/create-spdx.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index 15cccac84b..c4930b0de7 100644
--- a/meta/classes/create-spdx.bbclass
+++ b/meta/classes/create-spdx.bbclass
@@ -588,7 +588,7 @@ python do_create_spdx() {
 oe.sbom.write_doc(d, package_doc, "packages", 
indent=get_json_indent(d))
 }
 # NOTE: depending on do_unpack is a hack that is necessary to get it's 
dependencies for archive the source
-addtask do_create_spdx after do_package do_packagedata do_unpack before 
do_populate_sdk do_build do_rm_work
+addtask do_create_spdx after do_package_write_rpm do_package_write_ipk 
do_package_write_deb do_unpack before do_populate_sdk do_build do_rm_work
 
 SSTATETASKS += "do_create_spdx"
 do_create_spdx[sstate-inputdirs] = "${SPDXDEPLOY}"
-- 
2.37.1


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

Re: [OE-core] [kirkstone][master][PATCH] apt: fix do_package_qa failure

2022-07-28 Thread Alexander Kanavin 
On Thu, 28 Jul 2022 at 05:53, Changqing Li  wrote:
> An empty dir apt is installed under /var/log/. It should be ok to remove
> it since apt could create it when it doesn't exist.
>
> We have remove it for target. So I do the same for nativesdk. Another
> solution could be INSANE_SKIP the empty-dirs.
>
> How do you think?

That is fine, but please resend with this information in the commit message.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168596): 
https://lists.openembedded.org/g/openembedded-core/message/168596
Mute This Topic: https://lists.openembedded.org/mt/92643987/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] gstreamer1.0-plugins-bad: add PACKAGECONFIG for onevpl

2022-07-28 Thread Naveen Saini 
Please ignore this patch. It needs some re-work !

Regards,
Naveen

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Naveen Saini
> Sent: Thursday, July 28, 2022 12:47 PM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] gstreamer1.0-plugins-bad: add PACKAGECONFIG
> for onevpl
> 
> Allow user to build this plugin against MFX version 2.2+ (oneVPL)
> 
> https://github.com/GStreamer/gst-plugins-
> bad/commit/beda9a73339bef878e95798f629a868c647627ce
> 
> Signed-off-by: Naveen Saini 
> ---
>  .../gstreamer/gstreamer1.0-plugins-bad_1.20.3.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-
> bad_1.20.3.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-
> bad_1.20.3.bb
> index 2dd42395f7..6048e17214 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-
> bad_1.20.3.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-
> bad_1.20.3.bb
> @@ -97,6 +97,7 @@ PACKAGECONFIG[webrtcdsp]   = "-
> Dwebrtcdsp=enabled,-Dwebrtcdsp=disabled,webrt
>  PACKAGECONFIG[zbar]= "-Dzbar=enabled,-Dzbar=disabled,zbar"
>  PACKAGECONFIG[x11] = "-Dx11=enabled,-Dx11=disabled,libxcb
> libxkbcommon"
>  PACKAGECONFIG[x265]= "-Dx265=enabled,-Dx265=disabled,x265"
> +PACKAGECONFIG[onevpl]  = "-Dmsdk=enabled -Dmfx_api=oneVPL,-
> Dmsdk=disabled,onevpl onevpl-intel-gpu"
> 
>  GSTREAMER_GPL = "${@bb.utils.filter('PACKAGECONFIG', 'faad resindvd
> x265', d)}"
> 
> --
> 2.25.1


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