Re: [OE-core] [PATCH] Use shutil.move when os.rename fails

[Devendra Tewari]

Here's the correct link 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14301. I'll resubmit the 
patch referencing the bug in the commit message. Thanks.

> Em 30 de mar. de 2021, à(s) 18:59, Denys Dmytriyenko  
> escreveu:
> 
> The link is for a 10-year old bug, probably not what you wanted.
> Also, if a patch fixes existing bug in bugzilla, it needs to reference it in 
> commit message as well - [YOCTO#1234567]
> 
> 
>> On Mon, Mar 29, 2021 at 12:37:45PM -0300, Devendra Tewari wrote:
>> Also, this is due to https://bugzilla.yoctoproject.org/show_bug.cgi?id=1430.
>> 
 On 29 Mar 2021, at 12:35, Devendra Tewari  
 wrote:
>>> 
>>> Sure.
>>> 
>>> Would the following commit message be sufficient?
>>> 
>>>   Use shutil.move when os.rename fails
>>> 
>>>   Incremental build in Docker fails with
>>> 
>>>   OSError: [Errno 18] Invalid cross-device link
>>> 
>>>   When source and destination are on different overlay filesystems.
>>> 
>>>   This change handles the error with os.rename and retries with shutil.move.
>>> 
>>> Thanks,
>>> Devendra
>>> 
 On 29 Mar 2021, at 12:23, Konrad Weihmann  wrote:
 
 Yes please quote a bit from the python manpage [1] - I certainly see the 
 difference (and the edge cases where os.rename might fail), but that 
 should be documented as part of the commit message
 
 [1] https://docs.python.org/3/library/shutil.html#shutil.move
 
 On 29.03.21 17:21, Bruce Ashfield wrote:
> Can you document the cases that os.rename() is failing ? And also why
> would we expect the shutil.move() to work in those cases ?
> If a change like this cases issues in the future, we need that extra
> information in the commit head for proper triage.
> Bruce
> On Mon, Mar 29, 2021 at 11:16 AM Devendra Tewari
>  wrote:
>> 
>> ---
>> meta/classes/sstate.bbclass | 26 ++
>> 1 file changed, 22 insertions(+), 4 deletions(-)
>> 
>> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
>> index f579168162..f94aa96d70 100644
>> --- a/meta/classes/sstate.bbclass
>> +++ b/meta/classes/sstate.bbclass
>> @@ -384,6 +384,7 @@ def sstate_installpkg(ss, d):
>> def sstate_installpkgdir(ss, d):
>>import oe.path
>>import subprocess
>> +import shutil
>> 
>>sstateinst = d.getVar("SSTATE_INSTDIR")
>>d.setVar('SSTATE_FIXMEDIR', ss['fixmedir'])
>> @@ -401,7 +402,11 @@ def sstate_installpkgdir(ss, d):
>> 
>>for state in ss['dirs']:
>>prepdir(state[1])
>> -os.rename(sstateinst + state[0], state[1])
>> +try:
>> +os.rename(sstateinst + state[0], state[1])
>> +break
>> +except OSError:
>> +shutil.move(sstateinst + state[0], state[1])
>>sstate_install(ss, d)
>> 
>>for plain in ss['plaindirs']:
>> @@ -413,7 +418,11 @@ def sstate_installpkgdir(ss, d):
>>dest = plain
>>bb.utils.mkdirhier(src)
>>prepdir(dest)
>> -os.rename(src, dest)
>> +try:
>> +os.rename(src, dest)
>> +break
>> +except OSError:
>> +shutil.move(src, dest)
>> 
>>return True
>> 
>> @@ -638,6 +647,7 @@ python sstate_hardcode_path () {
>> 
>> def sstate_package(ss, d):
>>import oe.path
>> +import shutil
>> 
>>tmpdir = d.getVar('TMPDIR')
>> 
>> @@ -664,7 +674,11 @@ def sstate_package(ss, d):
>>continue
>>bb.error("sstate found an absolute path symlink %s 
>> pointing at %s. Please replace this with a relative link." % (srcpath, 
>> link))
>>bb.debug(2, "Preparing tree %s for packaging at %s" % (state[1], 
>> sstatebuild + state[0]))
>> -os.rename(state[1], sstatebuild + state[0])
>> +try:
>> +os.rename(state[1], sstatebuild + state[0])
>> +break
>> +except OSError:
>> +shutil.move(state[1], sstatebuild + state[0])
>> 
>>workdir = d.getVar('WORKDIR')
>>sharedworkdir = os.path.join(d.getVar('TMPDIR'), "work-shared")
>> @@ -674,7 +688,11 @@ def sstate_package(ss, d):
>>pdir = plain.replace(sharedworkdir, sstatebuild)
>>bb.utils.mkdirhier(plain)
>>bb.utils.mkdirhier(pdir)
>> -os.rename(plain, pdir)
>> +try:
>> +os.rename(plain, pdir)
>> +break
>> +except OSError:
>> +shutil.move(plain, pdir)
>> 
>>d.setVar('SSTATE_BUILDDIR', sstatebuild)
>>d.setVar('SSTATE_INSTDIR', sstatebuild)
>> --
>> 2.29.2
>> 
>> 
>> 
>> 
> 
>>> 
>> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150092): 

Re: [OE-core] [PATCH] Use shutil.move when os.rename fails

[Denys Dmytriyenko]

The link is for a 10-year old bug, probably not what you wanted.
Also, if a patch fixes existing bug in bugzilla, it needs to reference it in 
commit message as well - [YOCTO#1234567]


On Mon, Mar 29, 2021 at 12:37:45PM -0300, Devendra Tewari wrote:
> Also, this is due to https://bugzilla.yoctoproject.org/show_bug.cgi?id=1430.
> 
> > On 29 Mar 2021, at 12:35, Devendra Tewari  wrote:
> > 
> > Sure.
> > 
> > Would the following commit message be sufficient?
> > 
> >Use shutil.move when os.rename fails
> > 
> >Incremental build in Docker fails with
> > 
> >OSError: [Errno 18] Invalid cross-device link
> > 
> >When source and destination are on different overlay filesystems.
> > 
> >This change handles the error with os.rename and retries with 
> > shutil.move.
> > 
> > Thanks,
> > Devendra
> > 
> >> On 29 Mar 2021, at 12:23, Konrad Weihmann  wrote:
> >> 
> >> Yes please quote a bit from the python manpage [1] - I certainly see the 
> >> difference (and the edge cases where os.rename might fail), but that 
> >> should be documented as part of the commit message
> >> 
> >> [1] https://docs.python.org/3/library/shutil.html#shutil.move
> >> 
> >> On 29.03.21 17:21, Bruce Ashfield wrote:
> >>> Can you document the cases that os.rename() is failing ? And also why
> >>> would we expect the shutil.move() to work in those cases ?
> >>> If a change like this cases issues in the future, we need that extra
> >>> information in the commit head for proper triage.
> >>> Bruce
> >>> On Mon, Mar 29, 2021 at 11:16 AM Devendra Tewari
> >>>  wrote:
>  
>  ---
>  meta/classes/sstate.bbclass | 26 ++
>  1 file changed, 22 insertions(+), 4 deletions(-)
>  
>  diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
>  index f579168162..f94aa96d70 100644
>  --- a/meta/classes/sstate.bbclass
>  +++ b/meta/classes/sstate.bbclass
>  @@ -384,6 +384,7 @@ def sstate_installpkg(ss, d):
>  def sstate_installpkgdir(ss, d):
>  import oe.path
>  import subprocess
>  +import shutil
>  
>  sstateinst = d.getVar("SSTATE_INSTDIR")
>  d.setVar('SSTATE_FIXMEDIR', ss['fixmedir'])
>  @@ -401,7 +402,11 @@ def sstate_installpkgdir(ss, d):
>  
>  for state in ss['dirs']:
>  prepdir(state[1])
>  -os.rename(sstateinst + state[0], state[1])
>  +try:
>  +os.rename(sstateinst + state[0], state[1])
>  +break
>  +except OSError:
>  +shutil.move(sstateinst + state[0], state[1])
>  sstate_install(ss, d)
>  
>  for plain in ss['plaindirs']:
>  @@ -413,7 +418,11 @@ def sstate_installpkgdir(ss, d):
>  dest = plain
>  bb.utils.mkdirhier(src)
>  prepdir(dest)
>  -os.rename(src, dest)
>  +try:
>  +os.rename(src, dest)
>  +break
>  +except OSError:
>  +shutil.move(src, dest)
>  
>  return True
>  
>  @@ -638,6 +647,7 @@ python sstate_hardcode_path () {
>  
>  def sstate_package(ss, d):
>  import oe.path
>  +import shutil
>  
>  tmpdir = d.getVar('TMPDIR')
>  
>  @@ -664,7 +674,11 @@ def sstate_package(ss, d):
>  continue
>  bb.error("sstate found an absolute path symlink %s 
>  pointing at %s. Please replace this with a relative link." % (srcpath, 
>  link))
>  bb.debug(2, "Preparing tree %s for packaging at %s" % (state[1], 
>  sstatebuild + state[0]))
>  -os.rename(state[1], sstatebuild + state[0])
>  +try:
>  +os.rename(state[1], sstatebuild + state[0])
>  +break
>  +except OSError:
>  +shutil.move(state[1], sstatebuild + state[0])
>  
>  workdir = d.getVar('WORKDIR')
>  sharedworkdir = os.path.join(d.getVar('TMPDIR'), "work-shared")
>  @@ -674,7 +688,11 @@ def sstate_package(ss, d):
>  pdir = plain.replace(sharedworkdir, sstatebuild)
>  bb.utils.mkdirhier(plain)
>  bb.utils.mkdirhier(pdir)
>  -os.rename(plain, pdir)
>  +try:
>  +os.rename(plain, pdir)
>  +break
>  +except OSError:
>  +shutil.move(plain, pdir)
>  
>  d.setVar('SSTATE_BUILDDIR', sstatebuild)
>  d.setVar('SSTATE_INSTDIR', sstatebuild)
>  --
>  2.29.2
>  
>  
>  
>  
> >>> 
> > 
> 

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

Re: [OE-core] [oe-commits] [openembedded-core] 05/11: license.bbclass: Introduce AVAILABLE_LICENSES that lists all licenses

[Denys Dmytriyenko]

On Tue, Mar 30, 2021 at 10:46:19PM +0200, Martin Jansa wrote:
> On Tue, Jan 28, 2020 at 12:52 PM  wrote:
> 
> > This is an automated email from the git hooks/post-receive script.
> >
> > rpurdie pushed a commit to branch zeus
> > in repository openembedded-core.
> >
> > commit 5ed714139f91eb03871e01b68a4370784071234d
> > Author: Peter Kjellerstedt 
> > AuthorDate: Wed Dec 11 17:48:13 2019 +0100
> >
> > license.bbclass: Introduce AVAILABLE_LICENSES that lists all licenses
> >
> > Previously, there was SRC_DISTRIBUTE_LICENSES, an undocumented
> > variable that contained a static list of licenses. It was used by
> > expand_wildcard_licenses() to expand any wildcards used in, e.g.,
> > INCOMPATIBLE_LICENSE. However, since this static list of licenses has
> > not been kept up-to-date, many licenses were missing, with the result
> > that if one tried to use any of those licenses with a wildcard, no
> > licenses would be found, effectively ignoring that they should be
> > marked as incompatible.
> >
> > This introduces a new (documented) variable, AVAILABLE_LICENSES, that
> > is automatically updated to contain all licenses found in any
> > directories specified by ${COMMON_LICENSE_DIR} and ${LICENSE_PATH},
> > and uses it instead of SRC_DISTRIBUTE_LICENSES when expanding
> > wildcards.
> >
> > Signed-off-by: Peter Kjellerstedt 
> > Signed-off-by: Richard Purdie 
> > (cherry picked from commit 8c9ef587fe499c612a878a1ab42092eb79b334ef)
> > Signed-off-by: Anuj Mittal 
> > ---
> >  meta/classes/license.bbclass | 27
> > 
> >  meta/conf/documentation.conf |  1 +
> >  meta/lib/oeqa/selftest/cases/incompatible_lic.py |  6 +++---
> >  3 files changed, 27 insertions(+), 7 deletions(-)
> >
> ...
> 
> > +def available_licenses(d):
> > +"""
> > +Return the available licenses by searching the directories specified
> > by
> > +COMMON_LICENSE_DIR and LICENSE_PATH.
> > +"""
> > +lic_dirs = ((d.getVar('COMMON_LICENSE_DIR') or '') + ' ' +
> > +(d.getVar('LICENSE_PATH') or '')).split()
> > +
> > +licenses = []
> > +for lic_dir in lic_dirs:
> > +licenses += os.listdir(lic_dir)
> > +
> > +licenses = sorted(licenses)
> > +return licenses
> > +
> > +# Only determine the list of all available licenses once. This assumes
> > that any
> > +# additions to LICENSE_PATH have been done before this file is parsed.
> > +AVAILABLE_LICENSES := "${@' '.join(available_licenses(d))}"
> > +
> >
> 
> FWIW this part no longer seems to work correctly, now running:
> yocto-check-layer --dependency /OE/meta-openembedded/meta-oe/

Was it ever fixed?
https://lists.openembedded.org/g/openembedded-core/topic/72389694#141680

-- 
Regards,
Denys Dmytriyenko 
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

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

[OE-core] [RFT][PATCH 0/2] GCC 11 Pre-release

[Khem Raj]

This patchset updates to upcoming gcc 11 release, Please give it a try
in your test beds if you have cycles, since there is still sometime left
for final GCC 11 release perhaps we can squeeze in some bugfixes

They are also available via git here
https://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-11

Khem Raj (2):
  gcc: Upgrade to GCC 11
  libgcc-initial: Do not build fp128 to decimal ppc functions

 meta/conf/distro/include/tcmode-default.inc   |   2 +-
 .../gcc/{gcc-10.2.inc => gcc-11.0.inc}|  23 +-
 ...ian_10.2.bb => gcc-cross-canadian_11.0.bb} |   0
 .../{gcc-cross_10.2.bb => gcc-cross_11.0.bb}  |   0
 ...-crosssdk_10.2.bb => gcc-crosssdk_11.0.bb} |   0
 ...cc-runtime_10.2.bb => gcc-runtime_11.0.bb} |   0
 ...itizers_10.2.bb => gcc-sanitizers_11.0.bb} |   0
 ...{gcc-source_10.2.bb => gcc-source_11.0.bb} |   0
 ...-up-__aarch64_cas16_acq_rel-fallback.patch |  66 --
 ...ight-Line-Speculation-SLS-mitigation.patch | 202 --
 ...0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch |  10 +-
 ...libgomp-libitc-Fix-bootstrap-PR70454.patch | 208 --
 ...e-SLS-mitigation-for-RET-and-BR-inst.patch | 607 
 .../0002-gcc-poison-system-directories.patch  |  55 +-
 ...h64-Mitigate-SLS-for-BLR-instruction.patch | 658 --
 ...-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch |   6 +-
 .../gcc/gcc/0004-64-bit-multilib-hack.patch   |  10 +-
 .../gcc/gcc/0005-optional-libstdc.patch   |  26 +-
 .../gcc/gcc/0006-COLLECT_GCC_OPTIONS.patch|   6 +-
 ...ts.h-in-B-instead-of-S-and-t-oe-in-B.patch |  16 +-
 .../gcc/0008-fortran-cross-compile-hack.patch |  10 +-
 .../gcc/gcc/0009-cpp-honor-sysroot.patch  |  14 +-
 .../gcc/0010-MIPS64-Default-to-N64-ABI.patch  |   6 +-
 ...AMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch |  32 +-
 ...gcc-Fix-argument-list-too-long-error.patch |  11 +-
 .../gcc/gcc/0013-Disable-sdt.patch|  18 +-
 .../gcc/gcc/0014-libtool.patch|   2 +-
 ...s-fix-v4bx-to-linker-to-support-EABI.patch |   4 +-
 ...-config-files-from-B-instead-of-usin.patch |  14 +-
 ...ir-from-.la-which-usually-points-to-.patch |   2 +-
 .../gcc/gcc/0018-export-CPP.patch |   4 +-
 ...e-target-gcc-headers-can-be-included.patch |  12 +-
 ...t-directory-during-relink-if-inst_pr.patch |   2 +-
 ...IR-replacement-instead-of-hardcoding.patch |   4 +-
 ...22-aarch64-Add-support-for-musl-ldso.patch |   4 +-
 ...-fix-libcc1-s-install-path-and-rpath.patch |  10 +-
 ...le-sysroot-support-for-nativesdk-gcc.patch |  44 +-
 ...sroot-gcc-version-specific-dirs-with.patch |   8 +-
 ...ous-_FOR_BUILD-and-related-variables.patch |  18 +-
 ...027-nios2-Define-MUSL_DYNAMIC_LINKER.patch |   4 +-
 ...d-to-link-commandline-for-musl-targe.patch |  10 +-
 ...using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch |   4 +-
 .../0030-sync-gcc-stddef.h-with-musl.patch|   4 +-
 ...-fault-in-precompiled-header-generat.patch |   6 +-
 .../gcc/0032-Fix-for-testsuite-failure.patch  |   2 +-
 ...Re-introduce-spe-commandline-options.patch |  13 +-
 ...as-for-__cpu_indicator_init-instead-.patch |  12 +-
 ...s-Do-not-use-__LINE__-for-maintainin.patch |  34 +-
 ...ngw32-Enable-operation_not_supported.patch |   8 +-
 ...omic-Do-not-enforce-march-on-aarch64.patch |   8 +-
 .../gcc/{gcc_10.2.bb => gcc_11.0.bb}  |   0
 meta/recipes-devtools/gcc/libgcc-initial.inc  |   2 +
 ...initial_10.2.bb => libgcc-initial_11.0.bb} |   0
 .../gcc/{libgcc_10.2.bb => libgcc_11.0.bb}|   0
 ...ibgfortran_10.2.bb => libgfortran_11.0.bb} |   0
 55 files changed, 238 insertions(+), 1983 deletions(-)
 rename meta/recipes-devtools/gcc/{gcc-10.2.inc => gcc-11.0.inc} (82%)
 rename meta/recipes-devtools/gcc/{gcc-cross-canadian_10.2.bb => 
gcc-cross-canadian_11.0.bb} (100%)
 rename meta/recipes-devtools/gcc/{gcc-cross_10.2.bb => gcc-cross_11.0.bb} 
(100%)
 rename meta/recipes-devtools/gcc/{gcc-crosssdk_10.2.bb => 
gcc-crosssdk_11.0.bb} (100%)
 rename meta/recipes-devtools/gcc/{gcc-runtime_10.2.bb => gcc-runtime_11.0.bb} 
(100%)
 rename meta/recipes-devtools/gcc/{gcc-sanitizers_10.2.bb => 
gcc-sanitizers_11.0.bb} (100%)
 rename meta/recipes-devtools/gcc/{gcc-source_10.2.bb => gcc-source_11.0.bb} 
(100%)
 delete mode 100644 
meta/recipes-devtools/gcc/gcc/0001-aarch64-Fix-up-__aarch64_cas16_acq_rel-fallback.patch
 delete mode 100644 
meta/recipes-devtools/gcc/gcc/0001-aarch64-New-Straight-Line-Speculation-SLS-mitigation.patch
 delete mode 100644 
meta/recipes-devtools/gcc/gcc/0001-libatomic-libgomp-libitc-Fix-bootstrap-PR70454.patch
 delete mode 100644 
meta/recipes-devtools/gcc/gcc/0002-aarch64-Introduce-SLS-mitigation-for-RET-and-BR-inst.patch
 delete mode 100644 
meta/recipes-devtools/gcc/gcc/0003-aarch64-Mitigate-SLS-for-BLR-instruction.patch
 rename meta/recipes-devtools/gcc/{gcc_10.2.bb => gcc_11.0.bb} (100%)
 rename meta/recipes-devtools/gcc/{libgcc-initial_10.2.bb => 
libgcc-initial_11.0.bb} (100%)
 rename meta/recipes-devtools/gcc/{libgcc_10.2.bb => libgcc_11.0.bb} (100%)
 rename 

[OE-core] [PATCH 2/2] libgcc-initial: Do not build fp128 to decimal ppc functions

[Khem Raj]

These functions depend on glibc headers e.g.
stdlib.h/fenv.h/string.h/stdio.h which do not exist when building
lbgcc-initial, and these functions are not needed during glibc build
so we are fine to disable them

introdcued with [1]
[1] 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=781183595acba67a37c66f59a0c1d9b5fee7e248

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/libgcc-initial.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/gcc/libgcc-initial.inc 
b/meta/recipes-devtools/gcc/libgcc-initial.inc
index 06bf224f73..f7d8041226 100644
--- a/meta/recipes-devtools/gcc/libgcc-initial.inc
+++ b/meta/recipes-devtools/gcc/libgcc-initial.inc
@@ -51,6 +51,8 @@ do_configure_prepend () {
 
 do_configure_append () {
sed -i -e 's#thread_header = .*#thread_header = gthr-single.h#' 
${B}/${BPN}/Makefile
+   sed -i -e '/^libgcc_tm_defines = $/a fp128_dec_funcs =' 
${B}/${BPN}/Makefile
+   sed -i -e '/^libgcc_tm_defines = $/a fp128_decstr_funcs =' 
${B}/${BPN}/Makefile
 }
 
 do_install_append () {
-- 
2.31.1


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

Re: [OE-core] [oe-commits] [openembedded-core] 05/11: license.bbclass: Introduce AVAILABLE_LICENSES that lists all licenses

[Martin Jansa]

On Tue, Jan 28, 2020 at 12:52 PM  wrote:

> This is an automated email from the git hooks/post-receive script.
>
> rpurdie pushed a commit to branch zeus
> in repository openembedded-core.
>
> commit 5ed714139f91eb03871e01b68a4370784071234d
> Author: Peter Kjellerstedt 
> AuthorDate: Wed Dec 11 17:48:13 2019 +0100
>
> license.bbclass: Introduce AVAILABLE_LICENSES that lists all licenses
>
> Previously, there was SRC_DISTRIBUTE_LICENSES, an undocumented
> variable that contained a static list of licenses. It was used by
> expand_wildcard_licenses() to expand any wildcards used in, e.g.,
> INCOMPATIBLE_LICENSE. However, since this static list of licenses has
> not been kept up-to-date, many licenses were missing, with the result
> that if one tried to use any of those licenses with a wildcard, no
> licenses would be found, effectively ignoring that they should be
> marked as incompatible.
>
> This introduces a new (documented) variable, AVAILABLE_LICENSES, that
> is automatically updated to contain all licenses found in any
> directories specified by ${COMMON_LICENSE_DIR} and ${LICENSE_PATH},
> and uses it instead of SRC_DISTRIBUTE_LICENSES when expanding
> wildcards.
>
> Signed-off-by: Peter Kjellerstedt 
> Signed-off-by: Richard Purdie 
> (cherry picked from commit 8c9ef587fe499c612a878a1ab42092eb79b334ef)
> Signed-off-by: Anuj Mittal 
> ---
>  meta/classes/license.bbclass | 27
> 
>  meta/conf/documentation.conf |  1 +
>  meta/lib/oeqa/selftest/cases/incompatible_lic.py |  6 +++---
>  3 files changed, 27 insertions(+), 7 deletions(-)
>
...

> +def available_licenses(d):
> +"""
> +Return the available licenses by searching the directories specified
> by
> +COMMON_LICENSE_DIR and LICENSE_PATH.
> +"""
> +lic_dirs = ((d.getVar('COMMON_LICENSE_DIR') or '') + ' ' +
> +(d.getVar('LICENSE_PATH') or '')).split()
> +
> +licenses = []
> +for lic_dir in lic_dirs:
> +licenses += os.listdir(lic_dir)
> +
> +licenses = sorted(licenses)
> +return licenses
> +
> +# Only determine the list of all available licenses once. This assumes
> that any
> +# additions to LICENSE_PATH have been done before this file is parsed.
> +AVAILABLE_LICENSES := "${@' '.join(available_licenses(d))}"
> +
>

FWIW this part no longer seems to work correctly, now running:
yocto-check-layer --dependency /OE/meta-openembedded/meta-oe/
/OE/meta-openembedded/meta-python/ -- /OE/meta-openembedded/meta-multimedia/

I've noticed:
INFO:  ... ok
INFO: skipped "DistroCheckLayer: Layer meta-multimedia isn't Distro one."
INFO: ==
INFO: FAIL: test_signatures (common.CommonCheckLayer)
INFO: --
INFO: Traceback (most recent call last):
  File
"/OE/build/oe-core/openembedded-core/scripts/lib/checklayer/cases/common.py",
line 55, in test_signatures
self.fail('Adding layer %s changed signatures.\n%s' %
(self.tc.layer['name'], msg))
AssertionError: Adding layer meta-multimedia changed signatures.
88 signatures changed, initial differences (first hash before, second
after):
   libdevmapper:do_configure:
61d81f223c9ec5893d05cd355a0f9a6896841c2a1d957eb86c21eb7ce1ccad90 ->
6c38318b639496645b24971358c7c8e3d0d7b0f5ccd8575fab68c042678d4097
  bitbake-diffsigs --task libdevmapper do_configure --signature
61d81f223c9ec5893d05cd355a0f9a6896841c2a1d957eb86c21eb7ce1ccad90
6c38318b639496645b24971358c7c8e3d0d7b0f5ccd8575fab68c042678d4097
  NOTE: Reconnecting to bitbake server...
  basehash changed from
cf65d65a6575e76b468d41acd30ace204137f37eec43f3cf9bed00eb4c127086 to
e0a60ed74c1c002fea3f0883e173b2927c970c6b44c69e943b02d2d47bd1545f
  Variable AVAILABLE_LICENSES value changed:
  "AAL ACE-TAO-CIAO AFL-1.2 AFL-2.0 AFL-2.1 AFL-3.0 AGPL-3.0-only
AGPL-3.0-or-later ANTLR-PD {+AOM-Patent-License-1.0+} APL-1.0 APSL-1.0
APSL-1.1 APSL-1.2 APSL-2.0 Adobe Apache-1.0 Apache-1.1 Apache-2.0
Apache-2.0-with-LLVM-exception Arphic-Public-License Artistic-1.0
Artistic-2.0 BSD BSD-0-Clause BSD-1-Clause BSD-2-Clause BSD-2-Clause-Patent
BSD-3-Clause BSD-3-Clause-Clear BSD-4-Clause BSL-1.0 {+BellBird+}
BitstreamVera CATOSL-1.1 CC-BY-1.0 CC-BY-2.0 CC-BY-2.5 CC-BY-3.0
CC-BY-NC-1.0 CC-BY-NC-2.0 CC-BY-NC-2.5 CC-BY-NC-3.0 CC-BY-NC-ND-1.0
CC-BY-NC-ND-2.0 CC-BY-NC-ND-2.5 CC-BY-NC-ND-3.0 CC-BY-NC-SA-1.0
CC-BY-NC-SA-2.0 CC-BY-NC-SA-2.5 CC-BY-NC-SA-3.0 CC-BY-ND-1.0 CC-BY-ND-2.0
CC-BY-ND-2.5 CC-BY-ND-3.0 CC-BY-SA-1.0 CC-BY-SA-2.0 CC-BY-SA-2.5
CC-BY-SA-3.0 CC-BY-SA-4.0 CC0-1.0 CDDL-1.0 CECILL-1.0 CECILL-2.0 CECILL-B
CECILL-C {+CMU-Tex+} CPAL-1.0 CPL-1.0 CUA-OPL-1.0 ClArtistic DSSSL ECL-1.0
ECL-2.0 EDL-1.0 EFL-1.0 EFL-2.0 EPL-1.0 EPL-2.0 EUDatagrid EUPL-1.0
EUPL-1.1 Entessa ErlPL-1.1 FLTK FSF-Unlimited Fair Frameworx-1.0
{+Fraunhofer_FDK_AAC_Codec_Library_for_Android+} 

Re: [OE-core] [PATCH] kernel-yocto: log some kmeta information to assist in developing a bsp

[Yann Dirson]

Hi Bruce,

Le mar. 30 mars 2021 à 19:47, Bruce Ashfield
 a écrit :
>
> On Tue, Mar 30, 2021 at 1:27 PM Yann Dirson  
> wrote:
> >
> > From: Yann Dirson 
> >
> > This is not quite enough for the lack of a BSP to stand out clearly to
> > an unsuspecting user's eyes, but at least this line in the logs should
> > help some of us to get a clue:
> >
> >   NOTE: Using kmeta BSP ''
>
> Sorry, but no on this.
>
> There are already logs that are kept in the build directories
> themselves. They can be further exposed via some of the existing debug
> knobs that I have, but this is just noise in the general logs.

I must say I did not find any existing logs on this, where can I find them ?

>
> Cheers,
>
> Bruce
>
> >
> > Signed-off-by: Yann Dirson 
> > ---
> >  meta/classes/kernel-yocto.bbclass | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/classes/kernel-yocto.bbclass 
> > b/meta/classes/kernel-yocto.bbclass
> > index 35587dd564..c6228ad0b8 100644
> > --- a/meta/classes/kernel-yocto.bbclass
> > +++ b/meta/classes/kernel-yocto.bbclass
> > @@ -234,6 +234,7 @@ do_kernel_metadata() {
> > KMETA_EXTERNAL_BSPS="t"
> > fi
> > fi
> > +   bbnote "Using kmeta BSP '$bsp_definition'"
> > meta_dir=$(kgit --meta)
> >
> > KERNEL_FEATURES_FINAL=""
> > @@ -264,6 +265,7 @@ do_kernel_metadata() {
> > if [ "$mode" = "config" ]; then
> > # run1: pull all the configuration fragments, no matter 
> > where they come from
> > elements="`echo -n ${bsp_definition} $sccs_defconfig 
> > ${sccs} ${patches} $KERNEL_FEATURES_FINAL`"
> > +   bbnote "config: kmeta configuration fragments: $elements"
> > if [ -n "${elements}" ]; then
> > echo "${bsp_definition}" > 
> > ${S}/${meta_dir}/bsp_definition
> > scc --force -o ${S}/${meta_dir}:cfg,merge,meta 
> > ${includes} $sccs_defconfig $bsp_definition $sccs $patches 
> > $KERNEL_FEATURES_FINAL
> > @@ -283,6 +285,7 @@ do_kernel_metadata() {
> > if [ "$mode" = "patch" ]; then
> > # run2: only generate patches for elements that have been 
> > passed on the SRC_URI
> > elements="`echo -n ${sccs} ${patches} 
> > $KERNEL_FEATURES_FINAL`"
> > +   bbnote "patch: kmeta configuration fragments: $elements"
> > if [ -n "${elements}" ]; then
> > scc --force -o ${S}/${meta_dir}:patch --cmds patch 
> > ${includes} ${sccs} ${patches} $KERNEL_FEATURES_FINAL
> > if [ $? -ne 0 ]; then
> > --
> > 2.30.2
> >
> >
> > 
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



-- 
Yann Dirson 
Blade / Shadow -- http://shadow.tech

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150085): 
https://lists.openembedded.org/g/openembedded-core/message/150085
Mute This Topic: https://lists.openembedded.org/mt/81730505/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] kernel-yocto: log some kmeta information to assist in developing a bsp

[Bruce Ashfield]

On Tue, Mar 30, 2021 at 1:47 PM Bruce Ashfield via
lists.openembedded.org
 wrote:
>
> On Tue, Mar 30, 2021 at 1:27 PM Yann Dirson  
> wrote:
> >
> > From: Yann Dirson 
> >
> > This is not quite enough for the lack of a BSP to stand out clearly to
> > an unsuspecting user's eyes, but at least this line in the logs should
> > help some of us to get a clue:
> >
> >   NOTE: Using kmeta BSP ''
>
> Sorry, but no on this.
>
> There are already logs that are kept in the build directories
> themselves. They can be further exposed via some of the existing debug
> knobs that I have, but this is just noise in the general logs.

I should clarify that I can come up with some different logging, after
the upcoming release is done. I have old patches that have a variety
of different debug/development modes and I can resurrect them.

I'll open a feature in bugzilla to track it.

Bruce

>
> Cheers,
>
> Bruce
>
> >
> > Signed-off-by: Yann Dirson 
> > ---
> >  meta/classes/kernel-yocto.bbclass | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/classes/kernel-yocto.bbclass 
> > b/meta/classes/kernel-yocto.bbclass
> > index 35587dd564..c6228ad0b8 100644
> > --- a/meta/classes/kernel-yocto.bbclass
> > +++ b/meta/classes/kernel-yocto.bbclass
> > @@ -234,6 +234,7 @@ do_kernel_metadata() {
> > KMETA_EXTERNAL_BSPS="t"
> > fi
> > fi
> > +   bbnote "Using kmeta BSP '$bsp_definition'"
> > meta_dir=$(kgit --meta)
> >
> > KERNEL_FEATURES_FINAL=""
> > @@ -264,6 +265,7 @@ do_kernel_metadata() {
> > if [ "$mode" = "config" ]; then
> > # run1: pull all the configuration fragments, no matter 
> > where they come from
> > elements="`echo -n ${bsp_definition} $sccs_defconfig 
> > ${sccs} ${patches} $KERNEL_FEATURES_FINAL`"
> > +   bbnote "config: kmeta configuration fragments: $elements"
> > if [ -n "${elements}" ]; then
> > echo "${bsp_definition}" > 
> > ${S}/${meta_dir}/bsp_definition
> > scc --force -o ${S}/${meta_dir}:cfg,merge,meta 
> > ${includes} $sccs_defconfig $bsp_definition $sccs $patches 
> > $KERNEL_FEATURES_FINAL
> > @@ -283,6 +285,7 @@ do_kernel_metadata() {
> > if [ "$mode" = "patch" ]; then
> > # run2: only generate patches for elements that have been 
> > passed on the SRC_URI
> > elements="`echo -n ${sccs} ${patches} 
> > $KERNEL_FEATURES_FINAL`"
> > +   bbnote "patch: kmeta configuration fragments: $elements"
> > if [ -n "${elements}" ]; then
> > scc --force -o ${S}/${meta_dir}:patch --cmds patch 
> > ${includes} ${sccs} ${patches} $KERNEL_FEATURES_FINAL
> > if [ $? -ne 0 ]; then
> > --
> > 2.30.2
> >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>


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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150084): 
https://lists.openembedded.org/g/openembedded-core/message/150084
Mute This Topic: https://lists.openembedded.org/mt/81730505/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] kernel-yocto: log some kmeta information to assist in developing a bsp

[Bruce Ashfield]

On Tue, Mar 30, 2021 at 1:27 PM Yann Dirson  wrote:
>
> From: Yann Dirson 
>
> This is not quite enough for the lack of a BSP to stand out clearly to
> an unsuspecting user's eyes, but at least this line in the logs should
> help some of us to get a clue:
>
>   NOTE: Using kmeta BSP ''

Sorry, but no on this.

There are already logs that are kept in the build directories
themselves. They can be further exposed via some of the existing debug
knobs that I have, but this is just noise in the general logs.

Cheers,

Bruce

>
> Signed-off-by: Yann Dirson 
> ---
>  meta/classes/kernel-yocto.bbclass | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/classes/kernel-yocto.bbclass 
> b/meta/classes/kernel-yocto.bbclass
> index 35587dd564..c6228ad0b8 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -234,6 +234,7 @@ do_kernel_metadata() {
> KMETA_EXTERNAL_BSPS="t"
> fi
> fi
> +   bbnote "Using kmeta BSP '$bsp_definition'"
> meta_dir=$(kgit --meta)
>
> KERNEL_FEATURES_FINAL=""
> @@ -264,6 +265,7 @@ do_kernel_metadata() {
> if [ "$mode" = "config" ]; then
> # run1: pull all the configuration fragments, no matter where 
> they come from
> elements="`echo -n ${bsp_definition} $sccs_defconfig ${sccs} 
> ${patches} $KERNEL_FEATURES_FINAL`"
> +   bbnote "config: kmeta configuration fragments: $elements"
> if [ -n "${elements}" ]; then
> echo "${bsp_definition}" > 
> ${S}/${meta_dir}/bsp_definition
> scc --force -o ${S}/${meta_dir}:cfg,merge,meta 
> ${includes} $sccs_defconfig $bsp_definition $sccs $patches 
> $KERNEL_FEATURES_FINAL
> @@ -283,6 +285,7 @@ do_kernel_metadata() {
> if [ "$mode" = "patch" ]; then
> # run2: only generate patches for elements that have been 
> passed on the SRC_URI
> elements="`echo -n ${sccs} ${patches} $KERNEL_FEATURES_FINAL`"
> +   bbnote "patch: kmeta configuration fragments: $elements"
> if [ -n "${elements}" ]; then
> scc --force -o ${S}/${meta_dir}:patch --cmds patch 
> ${includes} ${sccs} ${patches} $KERNEL_FEATURES_FINAL
> if [ $? -ne 0 ]; then
> --
> 2.30.2
>
>
> 
>


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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150083): 
https://lists.openembedded.org/g/openembedded-core/message/150083
Mute This Topic: https://lists.openembedded.org/mt/81730505/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] buildhistory: add missing vardepsexcludes

[Christopher Larson]

On Tue, Mar 30, 2021 at 10:27 AM Christopher Larson via
lists.openembedded.org  wrote:

> For POPULATE_SDK_POST_TARGET_COMMAND, POPULATE_SDK_POST_HOST_COMMAND, and
> SDK_POSTPROCESS_COMMAND, the appropriate entries were added to
> vardepvalueexclude, but we want them in vardepsexclude as well.
>
>
Richard,

This fixes the failures
in sstatetests.SStateTests.test_sstate_noop_samesigs seen with my other
patch (image,populate_sdk_base: move 'func' flag setting for sdk command
vars) applied. Thanks.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150082): 
https://lists.openembedded.org/g/openembedded-core/message/150082
Mute This Topic: https://lists.openembedded.org/mt/81730511/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] buildhistory: add missing vardepsexcludes

[Christopher Larson]

For POPULATE_SDK_POST_TARGET_COMMAND, POPULATE_SDK_POST_HOST_COMMAND, and 
SDK_POSTPROCESS_COMMAND, the appropriate entries were added to 
vardepvalueexclude, but we want them in vardepsexclude as well.

Signed-off-by: Christopher Larson 
---
 meta/classes/buildhistory.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index 117a44eaf3..49af61c9c5 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -678,13 +678,16 @@ IMAGE_POSTPROCESS_COMMAND[vardepsexclude] += 
"buildhistory_get_imageinfo"
 POPULATE_SDK_POST_TARGET_COMMAND_append = " 
buildhistory_list_installed_sdk_target;"
 POPULATE_SDK_POST_TARGET_COMMAND_append = " 
buildhistory_get_sdk_installed_target;"
 POPULATE_SDK_POST_TARGET_COMMAND[vardepvalueexclude] .= "| 
buildhistory_list_installed_sdk_target;| buildhistory_get_sdk_installed_target;"
+POPULATE_SDK_POST_TARGET_COMMAND[vardepsexclude] += 
"buildhistory_list_installed_sdk_target buildhistory_get_sdk_installed_target"
 
 POPULATE_SDK_POST_HOST_COMMAND_append = " 
buildhistory_list_installed_sdk_host;"
 POPULATE_SDK_POST_HOST_COMMAND_append = " buildhistory_get_sdk_installed_host;"
 POPULATE_SDK_POST_HOST_COMMAND[vardepvalueexclude] .= "| 
buildhistory_list_installed_sdk_host;| buildhistory_get_sdk_installed_host;"
+POPULATE_SDK_POST_HOST_COMMAND[vardepsexclude] += 
"buildhistory_list_installed_sdk_host buildhistory_get_sdk_installed_host"
 
 SDK_POSTPROCESS_COMMAND_append = " buildhistory_get_sdkinfo ; 
buildhistory_get_extra_sdkinfo; "
 SDK_POSTPROCESS_COMMAND[vardepvalueexclude] .= "| buildhistory_get_sdkinfo ; 
buildhistory_get_extra_sdkinfo; "
+SDK_POSTPROCESS_COMMAND[vardepsexclude] += "buildhistory_get_sdkinfo 
buildhistory_get_extra_sdkinfo"
 
 python buildhistory_write_sigs() {
 if not "task" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
-- 
2.28.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150081): 
https://lists.openembedded.org/g/openembedded-core/message/150081
Mute This Topic: https://lists.openembedded.org/mt/81730511/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] kernel-yocto: log some kmeta information to assist in developing a bsp

[Yann Dirson]

From: Yann Dirson 

This is not quite enough for the lack of a BSP to stand out clearly to
an unsuspecting user's eyes, but at least this line in the logs should
help some of us to get a clue:

  NOTE: Using kmeta BSP ''

Signed-off-by: Yann Dirson 
---
 meta/classes/kernel-yocto.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 35587dd564..c6228ad0b8 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -234,6 +234,7 @@ do_kernel_metadata() {
KMETA_EXTERNAL_BSPS="t"
fi
fi
+   bbnote "Using kmeta BSP '$bsp_definition'"
meta_dir=$(kgit --meta)
 
KERNEL_FEATURES_FINAL=""
@@ -264,6 +265,7 @@ do_kernel_metadata() {
if [ "$mode" = "config" ]; then
# run1: pull all the configuration fragments, no matter where 
they come from
elements="`echo -n ${bsp_definition} $sccs_defconfig ${sccs} 
${patches} $KERNEL_FEATURES_FINAL`"
+   bbnote "config: kmeta configuration fragments: $elements"
if [ -n "${elements}" ]; then
echo "${bsp_definition}" > 
${S}/${meta_dir}/bsp_definition
scc --force -o ${S}/${meta_dir}:cfg,merge,meta 
${includes} $sccs_defconfig $bsp_definition $sccs $patches 
$KERNEL_FEATURES_FINAL
@@ -283,6 +285,7 @@ do_kernel_metadata() {
if [ "$mode" = "patch" ]; then
# run2: only generate patches for elements that have been 
passed on the SRC_URI
elements="`echo -n ${sccs} ${patches} $KERNEL_FEATURES_FINAL`"
+   bbnote "patch: kmeta configuration fragments: $elements"
if [ -n "${elements}" ]; then
scc --force -o ${S}/${meta_dir}:patch --cmds patch 
${includes} ${sccs} ${patches} $KERNEL_FEATURES_FINAL
if [ $? -ne 0 ]; then
-- 
2.30.2


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

[OE-core] Yocto Project Virtual Summit 2021

[Trevor Woerner]

The Yocto Project Summit Planning Committee is happy to announce the
upcoming 3rd Yocto Project Summit to take place Tuesday and Wednesday
May 25-26 2021, virtually.

The 2-day event will run in 2 tracks including a virtual developers meeting,
beginner tutorial sessions, hands-on intermediate instruction, lightning
talks, regular talks, and social events.

The cost for all attendees will be $40USD. The event will run both days from
noon until 8pm GMT. Registration is not yet open but will be shortly, please
watch for further announcements.

The call for papers is now open and will close at 11:59 PM PST on Sunday,
April 25, 2021. To submit a proposal please visit:
https://pretalx.com/yocto-project-summit-2021/cfp

For more information please visit:
https://www.yoctoproject.org/yocto-project-virtual-summit-2021/

We look forward to seeing you at the conference!

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

[OE-core] Yocto Project Status WW13`21

[Stephen Jolley]

Current Dev Position: YP 3.3 M4 (Feature Freeze)

Next Deadline: 5th April 2021 YP 3.3 M4 build

 

Next Team Meetings:

*   Bug Triage meeting Thursday Apr. 1st at 7:30am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Monthly Project Meeting Tuesday Apr. 6th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Weekly Engineering Sync Tuesday Mar. 30th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 3.3 M3 has been released, the issue with beaglebone was resolved.
*   YP 3.2.3 has been built and is in QA.
*   It was a quiet week for patches whilst the M3 issues were resolved.
We're not taking non-essential version upgrades at this point. There are
some tweaks to meson's native build handling and some selftest parallelism
unittest output handling fixes pending.
*   Intermittent autobuilder issues continue to occur and are now at a
record high level. You can see the list of failures we're continuing to see
by searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We are working to identify the load pattern on the infrastructure that seems
to trigger these.

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 3.3. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.3_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.

 

YP 3.3 Milestone Dates:

*   YP 3.3 M3 has been released.
*   YP 3.3 M4 build date 2021/04/05
*   YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

*   YP 3.2.3 is in QA.
*   YP 3.1.7 build date 2021/03/29
*   YP 3.1.7 release date 2021/04/09
*   YP 3.2.4 build date 2021/05/3
*   YP 3.2.4 release date 2021/05/14
*   YP 3.1.8 build date 2021/05/17
*   YP 3.1.8 release date 2021/05/28

 

Tracking Metrics:

*   WDD 2751 (last week 2748) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics

*   Total patches found: 1317 (last week 1309)
*   Patches in the Pending State: 493 (37%) [last week 492 (38%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150077): 
https://lists.openembedded.org/g/openembedded-core/message/150077
Mute This Topic: https://lists.openembedded.org/mt/81723525/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] sqlite3: upgrade 3.35.0 -> 3.35.3

[Randy MacLeod]

Signed-off-by: Randy MacLeod 
---
 .../sqlite/{sqlite3_3.35.0.bb => sqlite3_3.35.3.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-support/sqlite/{sqlite3_3.35.0.bb => sqlite3_3.35.3.bb} 
(83%)

diff --git a/meta/recipes-support/sqlite/sqlite3_3.35.0.bb 
b/meta/recipes-support/sqlite/sqlite3_3.35.3.bb
similarity index 83%
rename from meta/recipes-support/sqlite/sqlite3_3.35.0.bb
rename to meta/recipes-support/sqlite/sqlite3_3.35.3.bb
index 127065bbc1..459dcbd4c8 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.35.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.35.3.bb
@@ -4,7 +4,7 @@ LICENSE = "PD"
 LIC_FILES_CHKSUM = 
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66"
 
 SRC_URI = "http://www.sqlite.org/2021/sqlite-autoconf-${SQLITE_PV}.tar.gz;
-SRC_URI[sha256sum] = 
"3dfb3f143c83695a555c7dd9e06ed924f9d273c287989874e102656724baf2d0"
+SRC_URI[sha256sum] = 
"ecbccdd440bdf32c0e1bb3611d635239e3b5af268248d130d0445a32daf0274b"
 
 # -19242 is only an issue in specific development branch commits
 CVE_CHECK_WHITELIST += "CVE-2019-19242"
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150076): 
https://lists.openembedded.org/g/openembedded-core/message/150076
Mute This Topic: https://lists.openembedded.org/mt/81722469/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] Use shutil.move when os.rename fails

[Devendra Tewari]

I understand that parallel tasks can result in such issues, but would expect 
some kind of dependency graph that would prevent them from happening. I wish I 
had more time to understand the issue fully.

Here’s the last version of my patch that still uses os.rename, and on error 
uses shutil.move, with the reasoning explained in the commit message. There are 
tons of os.rename in code elsewhere, and I’ve encountered similar issues when 
doing incremental builds, but I’ll leave fixing them to those with more time at 
hand. Cheers.

From aeba1f9728f69cdf2ce4ba285be86761d8024f9d Mon Sep 17 00:00:00 2001
From: Devendra Tewari 
Date: Tue, 30 Mar 2021 08:27:40 -0300
Subject: [PATCH] Use shutil.move when os.rename fails

Incremental build in Docker fails with

OSError: [Errno 18] Invalid cross-device link

When source and destination are on different overlay filesystems.

This change handles error with os.rename and retries with shutil.move.
The reason os.rename is still used is because shutil.move is too slow
for speed sensitive sections of code.
---
 meta/classes/sstate.bbclass | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index f579168162..301dfc27db 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -384,6 +384,7 @@ def sstate_installpkg(ss, d):
 def sstate_installpkgdir(ss, d):
 import oe.path
 import subprocess
+import shutil
 
 sstateinst = d.getVar("SSTATE_INSTDIR")
 d.setVar('SSTATE_FIXMEDIR', ss['fixmedir'])
@@ -401,7 +402,10 @@ def sstate_installpkgdir(ss, d):
 
 for state in ss['dirs']:
 prepdir(state[1])
-os.rename(sstateinst + state[0], state[1])
+try:
+os.rename(sstateinst + state[0], state[1])
+except OSError:
+shutil.move(sstateinst + state[0], state[1])
 sstate_install(ss, d)
 
 for plain in ss['plaindirs']:
@@ -413,7 +417,10 @@ def sstate_installpkgdir(ss, d):
 dest = plain
 bb.utils.mkdirhier(src)
 prepdir(dest)
-os.rename(src, dest)
+try:
+os.rename(src, dest)
+except OSError:
+shutil.move(src, dest)
 
 return True
 
@@ -638,6 +645,7 @@ python sstate_hardcode_path () {
 
 def sstate_package(ss, d):
 import oe.path
+import shutil
 
 tmpdir = d.getVar('TMPDIR')
 
@@ -664,7 +672,10 @@ def sstate_package(ss, d):
 continue
 bb.error("sstate found an absolute path symlink %s pointing at 
%s. Please replace this with a relative link." % (srcpath, link))
 bb.debug(2, "Preparing tree %s for packaging at %s" % (state[1], 
sstatebuild + state[0]))
-os.rename(state[1], sstatebuild + state[0])
+try:
+os.rename(state[1], sstatebuild + state[0])
+except OSError:
+shutil.move(state[1], sstatebuild + state[0])
 
 workdir = d.getVar('WORKDIR')
 sharedworkdir = os.path.join(d.getVar('TMPDIR'), "work-shared")
@@ -674,7 +685,10 @@ def sstate_package(ss, d):
 pdir = plain.replace(sharedworkdir, sstatebuild)
 bb.utils.mkdirhier(plain)
 bb.utils.mkdirhier(pdir)
-os.rename(plain, pdir)
+try:
+os.rename(plain, pdir)
+except OSError:
+shutil.move(plain, pdir)
 
 d.setVar('SSTATE_BUILDDIR', sstatebuild)
 d.setVar('SSTATE_INSTDIR', sstatebuild)
-- 
2.29.2


> On 30 Mar 2021, at 08:10, Richard Purdie  
> wrote:
> 
> On Mon, 2021-03-29 at 16:00 -0700, Andre McCurdy wrote:
>> On Mon, Mar 29, 2021 at 3:45 PM Devendra Tewari
>>  wrote:
>>> 
>>> Thanks! My bad. The example I looked up in Python docs had a break and I 
>>> just realized it was a looping example.
>>> 
>>> Here’s the updated patch (or should I submit it again via git send-email?)
>> 
>> It would be better to use shutil.move unconditionally in all cases,
>> rather than have a separate shutil.move code path which only gets
>> tested by people doing incremental builds in docker.
> 
> This is a speed sensitive section of code and shutil has traditionally proved 
> to be slow so I disagree with that, rename is very much preferred here where
> we can.
> 
> Cheers,
> 
> Richard
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150074): 
https://lists.openembedded.org/g/openembedded-core/message/150074
Mute This Topic: https://lists.openembedded.org/mt/81698791/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] Use shutil.move when os.rename fails

[Richard Purdie]

On Mon, 2021-03-29 at 16:00 -0700, Andre McCurdy wrote:
> On Mon, Mar 29, 2021 at 3:45 PM Devendra Tewari
>  wrote:
> > 
> > Thanks! My bad. The example I looked up in Python docs had a break and I 
> > just realized it was a looping example.
> > 
> > Here’s the updated patch (or should I submit it again via git send-email?)
> 
> It would be better to use shutil.move unconditionally in all cases,
> rather than have a separate shutil.move code path which only gets
> tested by people doing incremental builds in docker.

This is a speed sensitive section of code and shutil has traditionally proved 
to be slow so I disagree with that, rename is very much preferred here where
we can.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150073): 
https://lists.openembedded.org/g/openembedded-core/message/150073
Mute This Topic: https://lists.openembedded.org/mt/81698791/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] Use shutil.move when os.rename fails

[Devendra Tewari]

With the following patch

From f29ec67239094a256fcfc119fb75be90923d3448 Mon Sep 17 00:00:00 2001
From: Devendra Tewari 
Date: Mon, 29 Mar 2021 21:11:56 -0300
Subject: [PATCH] Use shutil.move to rename sstate

Incremental build in Docker fails with

OSError: [Errno 18] Invalid cross-device link

When source and destination are on different overlay filesystems.

shutil.move uses os.rename when destination is on the current filesystem,
otherwise source is copied to destination and then removed.
---
 meta/classes/sstate.bbclass | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index f579168162..2e87697e3e 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -384,6 +384,7 @@ def sstate_installpkg(ss, d):
 def sstate_installpkgdir(ss, d):
 import oe.path
 import subprocess
+import shutil
 
 sstateinst = d.getVar("SSTATE_INSTDIR")
 d.setVar('SSTATE_FIXMEDIR', ss['fixmedir'])
@@ -401,7 +402,7 @@ def sstate_installpkgdir(ss, d):
 
 for state in ss['dirs']:
 prepdir(state[1])
-os.rename(sstateinst + state[0], state[1])
+shutil.move(sstateinst + state[0], state[1])
 sstate_install(ss, d)
 
 for plain in ss['plaindirs']:
@@ -413,7 +414,7 @@ def sstate_installpkgdir(ss, d):
 dest = plain
 bb.utils.mkdirhier(src)
 prepdir(dest)
-os.rename(src, dest)
+shutil.move(src, dest)
 
 return True
 
@@ -638,6 +639,7 @@ python sstate_hardcode_path () {
 
 def sstate_package(ss, d):
 import oe.path
+import shutil
 
 tmpdir = d.getVar('TMPDIR')
 
@@ -664,7 +666,7 @@ def sstate_package(ss, d):
 continue
 bb.error("sstate found an absolute path symlink %s pointing at 
%s. Please replace this with a relative link." % (srcpath, link))
 bb.debug(2, "Preparing tree %s for packaging at %s" % (state[1], 
sstatebuild + state[0]))
-os.rename(state[1], sstatebuild + state[0])
+shutil.move(state[1], sstatebuild + state[0])
 
 workdir = d.getVar('WORKDIR')
 sharedworkdir = os.path.join(d.getVar('TMPDIR'), "work-shared")
@@ -674,7 +676,7 @@ def sstate_package(ss, d):
 pdir = plain.replace(sharedworkdir, sstatebuild)
 bb.utils.mkdirhier(plain)
 bb.utils.mkdirhier(pdir)
-os.rename(plain, pdir)
+shutil.move(plain, pdir)
 
 d.setVar('SSTATE_BUILDDIR', sstatebuild)
 d.setVar('SSTATE_INSTDIR', sstatebuild)
-- 
2.29.2

The build fails with

#12 2734.2 2021-03-30 01:14:29 - INFO - NOTE: recipe 
linux-libc-headers-5.10-r0: task do_package_write_rpm: Started
#12 2734.4 2021-03-30 01:14:29 - INFO - NOTE: recipe lzo-native-2.10-r0: 
task do_prepare_recipe_sysroot: Started
#12 2734.8 2021-03-30 01:14:30 - INFO - NOTE: recipe lzo-native-2.10-r0: 
task do_prepare_recipe_sysroot: Succeeded
#12 2734.9 2021-03-30 01:14:30 - INFO - NOTE: Running task 2441 of 4982 
(virtual:native:/home/pi/docker-meta-raspberrypi/layers/poky/meta/recipes-support/lzo/lzo_2.10.bb:do_configure)
#12 2735.0 2021-03-30 01:14:30 - ERROR- ERROR: linux-libc-headers-5.10-r0 
do_package_write_rpm: Error executing a python function in exec_python_func() 
autogenerated:
#12 2735.0 2021-03-30 01:14:30 - ERROR- 
#12 2735.0 2021-03-30 01:14:30 - ERROR- The stack trace of python calls 
that resulted in this exception/failure was:
#12 2735.0 2021-03-30 01:14:30 - ERROR- File: 'exec_python_func() 
autogenerated', lineno: 2, function: 
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0001:
#12 2735.0 2021-03-30 01:14:30 - ERROR- *** 0002:write_specfile(d)
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0003:
#12 2735.0 2021-03-30 01:14:30 - ERROR- File: 
'/home/pi/docker-meta-raspberrypi/layers/poky/meta/classes/package_rpm.bbclass',
 lineno: 342, function: write_specfile
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0338:
localdata.setVar('PKG', pkgname)
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0339:
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0340:
localdata.setVar('OVERRIDES', d.getVar("OVERRIDES", False) + ":" + pkg)
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0341:
#12 2735.0 2021-03-30 01:14:30 - ERROR- *** 0342:conffiles = 
get_conffiles(pkg, d)
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0343:dirfiles = 
localdata.getVar('DIRFILES')
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0344:if dirfiles is not 
None:
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0345:dirfiles = 
dirfiles.split()
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0346:
#12 2735.0 2021-03-30 01:14:30 - ERROR- File: 
'/home/pi/docker-meta-raspberrypi/layers/poky/meta/classes/package.bbclass', 
lineno: 304, function: get_conffiles
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0300:def get_conffiles(pkg, d):
#12 2735.0 2021-03-30 01:14:30 - ERROR- 0301:pkgdest = 
d.getVar('PKGDEST')
#12 2735.0 

[OE-core] [PATCH 1/2] perl: allow empty lines and comments in perl-rdepends.txt

[Awais Belal]

With this change the rdepends file can now have empty lines
and comment lines. The perl-rdepends.txt generation will be
fixed with further commits to leverage this change.

Signed-off-by: Awais Belal 
---
 meta/recipes-devtools/perl/perl_5.32.1.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/perl/perl_5.32.1.bb 
b/meta/recipes-devtools/perl/perl_5.32.1.bb
index 1fafc0a8c9..65db6da2b5 100644
--- a/meta/recipes-devtools/perl/perl_5.32.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.32.1.bb
@@ -320,6 +320,9 @@ python split_perl_packages () {
 # Read the pre-generated dependency file, and use it to set module 
dependecies
 for line in open(d.expand("${WORKDIR}") + 
'/perl-rdepends.txt').readlines():
 splitline = line.split()
+# Filter empty lines and comments
+if len(splitline) == 0 or splitline[0].startswith("#"):
+continue
 if bb.data.inherits_class('native', d):
 module = splitline[0] + '-native'
 depends = "perl-native"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150070): 
https://lists.openembedded.org/g/openembedded-core/message/150070
Mute This Topic: https://lists.openembedded.org/mt/81716799/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] perl: fix creation and generate new perl-rdepends.txt

[Awais Belal]

The creation of perl-rdepends.txt simply copied over the
generated list (perl-rdepends.generated) to perl-rdepends.txt
while missing out the manual dependencies placed in
perl-rdepends.inc. This caused missing runtime dependencies.
Additionally, the mechanism always appended which then
produced duplicated lines in perl-rdepends.txt if the creation
function is run multiple times.
We now concatenate both the .inc and .generated to the final
.txt so manual and generated both types of dependencies make
it to the final configuration. A new perl-rdepends.txt is then
generated with these fixes.

Signed-off-by: Awais Belal 
---
 meta/recipes-devtools/perl/files/perl-rdepends.txt | 8 
 meta/recipes-devtools/perl/perl_5.32.1.bb  | 4 ++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/perl/files/perl-rdepends.txt 
b/meta/recipes-devtools/perl/files/perl-rdepends.txt
index e7cd551988..f20fc44b58 100644
--- a/meta/recipes-devtools/perl/files/perl-rdepends.txt
+++ b/meta/recipes-devtools/perl/files/perl-rdepends.txt
@@ -1,3 +1,11 @@
+
+# Some additional dependencies that the above doesn't manage to figure out
+RDEPENDS_perl-module-file-spec += "perl-module-file-spec-unix"
+RDEPENDS_perl-module-math-bigint += "perl-module-math-bigint-calc"
+RDEPENDS_perl-module-thread-queue += "perl-module-attributes"
+RDEPENDS_perl-module-overload += "perl-module-overloading"
+
+# Generated depends list beyond this line
 RDEPENDS_perl-module-anydbm-file += "perl-module-strict"
 RDEPENDS_perl-module-anydbm-file += "perl-module-warnings"
 RDEPENDS_perl-module-app-cpan += "perl-module-config"
diff --git a/meta/recipes-devtools/perl/perl_5.32.1.bb 
b/meta/recipes-devtools/perl/perl_5.32.1.bb
index 65db6da2b5..b28040c7fb 100644
--- a/meta/recipes-devtools/perl/perl_5.32.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.32.1.bb
@@ -370,8 +370,8 @@ EOPREAMBLE
 sort -u | \
 sed 
's/^/RDEPENDS_/;s/perl-module-/${PN}-module-/g;s/module-\(module-\)/\1/g;s/\(module-load\)-conditional/\1/g;s/encode-configlocal/&-pm/;'
 | \
 egrep -wv 
'=>|module-a|module-apache.?|module-apr|module-authen-sasl|module-b-asmdata|module-convert-ebcdic|module-devel-size|module-digest-perl-md5|module-dumpvalue|module-extutils-constant-aaargh56hash|module-extutils-xssymset|module-file-bsdglob|module-for|module-it|module-io-socket-inet6|module-io-socket-ssl|module-io-string|module-ipc-system-simple|module-lexical|module-local-lib|metadata|module-modperl-util|module-pluggable-object|module-test-builder-io-scalar|module-test2|module-text-unidecode|module-unicore|module-win32|objects\sload|syscall.ph|systeminfo.ph|%s'
 | \
-egrep -wv 
'=>|module-algorithm-diff|module-carp|module-c|module-encode-hanextra|module-extutils-makemaker-version-regex|module-file-spec|module-io-compress-lzma|module-locale-maketext-lexicon|module-log-agent|module-meta-notation|module-net-localcfg|module-net-ping-external|module-b-deparse|module-scalar-util|module-some-module|module-symbol|module-uri|module-win32api-file'
 >> ${WORKDIR}/perl-rdepends.generated
-cp ${WORKDIR}/perl-rdepends.generated ${THISDIR}/files/perl-rdepends.txt
+egrep -wv 
'=>|module-algorithm-diff|module-carp|module-c|module-l|module-encode-hanextra|module-extutils-makemaker-version-regex|module-file-spec|module-io-compress-lzma|module-io-uncompress-unxz|module-locale-maketext-lexicon|module-log-agent|module-meta-notation|module-net-localcfg|module-net-ping-external|module-b-deparse|module-scalar-util|module-some-module|module-symbol|module-uri|module-win32api-file'
 > ${WORKDIR}/perl-rdepends.generated
+cat ${WORKDIR}/perl-rdepends.inc ${WORKDIR}/perl-rdepends.generated > 
${THISDIR}/files/perl-rdepends.txt
 }
 
 # bitbake perl -c create_rdepends_inc
-- 
2.17.1


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