Re: [OE-core][PATCH] Revert "vim: do not adjust script paths building for target"

[Richard Purdie]

On Fri, 2020-06-05 at 10:13 +0800, Chen Qi wrote:
> This reverts commit 8972fe5581b9fe8ef14d539001758bb13bca6737.
> 
> The above commit causes regression when vim-tools is installed.
> The error is like below.
> 
> Error:
>  Problem: conflicting requests
>- nothing provides /bin/csh needed by vim-tools-8.2-r0.corei7_64
>- nothing provides /usr/bin/nawk needed by vim-tools-8.2-r0.corei7_64
>- nothing provides /usr/bin/python needed by vim-tools-8.2-r0.corei7_64
> 
> Signed-off-by: Chen Qi 
> ---
>  .../vim/files/no-path-adjust.patch| 27 ---
>  meta/recipes-support/vim/vim.inc  | 12 -
>  2 files changed, 6 insertions(+), 33 deletions(-)
>  delete mode 100644 meta/recipes-support/vim/files/no-path-adjust.patch
> 
> diff --git a/meta/recipes-support/vim/files/no-path-adjust.patch 
> b/meta/recipes-support/vim/files/no-path-adjust.patch
> deleted file mode 100644
> index 05c2d803f6..00
> --- a/meta/recipes-support/vim/files/no-path-adjust.patch
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -vim: do not adjust script pathnames
> -
> -When cross-compiling, we do not want to reference the host versions of
> -things like perl and awk.
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Joe Slater 
> -
>  a/src/Makefile
> -+++ b/src/Makefile
> -@@ -2507,11 +2507,14 @@ installtools: $(TOOLS) $(DESTDIR)$(exec_
> -  rm -rf $$cvs; \
> -   fi
> - -chmod $(FILEMOD) $(DEST_TOOLS)/*
> --# replace the path in some tools
> -+
> -+# replace the path in some tools, but not when cross-compiling
> -+ifneq ($(CROSS_COMPILING),1)
> - perlpath=`./which.sh perl` && sed -e "s+/usr/bin/perl+$$perlpath+" 
> $(TOOLSSOURCE)/efm_perl.pl >$(DEST_TOOLS)/efm_perl.pl
> - awkpath=`./which.sh nawk` && sed -e "s+/usr/bin/nawk+$$awkpath+" 
> $(TOOLSSOURCE)/mve.awk >$(DEST_TOOLS)/mve.awk; if test -z "$$awkpath"; then \
> - awkpath=`./which.sh gawk` && sed -e 
> "s+/usr/bin/nawk+$$awkpath+" $(TOOLSSOURCE)/mve.awk >$(DEST_TOOLS)/mve.awk; 
> if test -z "$$awkpath"; then \
> - awkpath=`./which.sh awk` && sed -e "s+/usr/bin/nawk+$$awkpath+" 
> $(TOOLSSOURCE)/mve.awk >$(DEST_TOOLS)/mve.awk; fi; fi
> -+endif
> - -chmod $(SCRIPTMOD) `grep -l "^#!" $(DEST_TOOLS)/*`
> - 
> - # install the language specific files for tools, if they were unpacked


If we're going to install these files which you're still doing, we want
to use target paths, not host ones?

I suspect we therefore need this and your changes rather than removing
this patch?

Cheers,

Richard


> diff --git a/meta/recipes-support/vim/vim.inc 
> b/meta/recipes-support/vim/vim.inc
> index 9f3dc08027..78e3f9528d 100644
> --- a/meta/recipes-support/vim/vim.inc
> +++ b/meta/recipes-support/vim/vim.inc
> @@ -11,7 +11,6 @@ SRC_URI = "git://github.com/vim/vim.git \
> file://disable_acl_header_check.patch \
> file://vim-add-knob-whether-elf.h-are-checked.patch \
> file://0001-src-Makefile-improve-reproducibility.patch \
> -   file://no-path-adjust.patch \
>  "
>  SRCREV = "98056533b96b6b5d8849641de93185dd7bcadc44"
>  
> @@ -83,6 +82,12 @@ EXTRA_OECONF = " \
>  do_install() {
>  autotools_do_install
>  
> +# Work around file-rdeps picking up csh, awk, perl or python as a dep
> +chmod -x ${D}${datadir}/${BPN}/${VIMDIR}/tools/vim132
> +chmod -x ${D}${datadir}/${BPN}/${VIMDIR}/tools/mve.awk
> +chmod -x ${D}${datadir}/${BPN}/${VIMDIR}/tools/*.pl
> +chmod -x ${D}${datadir}/${BPN}/${VIMDIR}/tools/*.py
> +
>  # Install example vimrc from runtime files
>  install -m 0644 runtime/vimrc_example.vim ${D}/${datadir}/${BPN}/vimrc
>  
> @@ -105,12 +110,7 @@ FILES_${PN}-help = "${datadir}/${BPN}/${VIMDIR}/doc"
>  FILES_${PN}-tutor = "${datadir}/${BPN}/${VIMDIR}/tutor ${bindir}/${BPN}tutor"
>  FILES_${PN}-vimrc = "${datadir}/${BPN}/vimrc"
>  FILES_${PN}-data = "${datadir}/${BPN}"
> -
> -# We do not want to complain if perl or gawk are not on the target.
> -#
>  FILES_${PN}-tools = "${datadir}/${BPN}/${VIMDIR}/tools"
> -INSANE_SKIP_${PN}-tools = "file-rdeps"
> -
>  FILES_${PN}-common = " \
>  ${datadir}/${BPN}/${VIMDIR}/*.vim \
>  ${datadir}/${BPN}/${VIMDIR}/autoload \
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139248): 
https://lists.openembedded.org/g/openembedded-core/message/139248
Mute This Topic: https://lists.openembedded.org/mt/74685328/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 v7 0/3] Add a new bbclass that abstracts the generation of FIT blobs

[Richard Purdie]

On Wed, 2020-05-27 at 09:05 +0300, Nandor Han wrote:
> Description
> --
> Add a new class and unittest for generating FIT blobs.
> 
> 
> Testing
> ---
> 
> 1. linux-yocto_5.4.bbappend was modified to have the following
> configuration:
> 
> ```
> inherit fit-image
> 
> KERNEL_IMAGE_NODE[name] = "kernel"
> KERNEL_IMAGE_NODE[description] = "${PF}"
> KERNEL_IMAGE_NODE[data] =
> '/incbin/("./arch/${ARCH}/boot/zImage")'
> KERNEL_IMAGE_NODE[type] = "kernel"
> KERNEL_IMAGE_NODE[arch] = "${ARCH}"
> KERNEL_IMAGE_NODE[os] = "linux"
> KERNEL_IMAGE_NODE[compression] = "none"
> KERNEL_IMAGE_NODE[load] = "${UBOOT_LOADADDRESS}"
> KERNEL_IMAGE_NODE[entry] = "${UBOOT_ENTRYPOINT}"
> KERNEL_IMAGE_NODE[hash] = "sha256"
> 
> FDT_IMAGE_NODE[name] = "fdt"
> FDT_IMAGE_NODE[description] = "FDT blob"
> FDT_IMAGE_NODE[data] = '/incbin/("./arch/${ARCH}/boot/dts/am335x-
> bone.dtb")'
> FDT_IMAGE_NODE[type] = "flat_dt"
> FDT_IMAGE_NODE[arch] = "${ARCH}"
> FDT_IMAGE_NODE[compression] = "none"
> FDT_IMAGE_NODE[hash] = "sha256"
> 
> CONF1_CONF_NODE[name] = "conf"
> CONF1_CONF_NODE[description] = "Linux kernel and FDT blob"
> CONF1_CONF_NODE[kernel] = "kernel"
> CONF1_CONF_NODE[fdt] = "fdt"
> 
> FIT_IMAGES_NODE = "KERNEL_IMAGE_NODE FDT_IMAGE_NODE"
> FIT_CONFIGURATIONS_NODE = "CONF1_CONF_NODE"
> FIT_CONFIGURATIONS_NODE[default] = "${@d.getVarFlag('CONF1_CONF_N
> ODE', 'name') or ""}"
> ```
> 2. Build the kernel: `bitbake virtual/kernel`
> 3. Verify that `image-fit.itb` is present in the build directory:
> PASS
> 4. Disassemble the image using the command: `dtc -I dtb -O dts
> image-fit.itb`
> 5. Verify that the FIT source contains the expected
> configuration: PASS
> 6. Run the unittest using the command: `oe-selftest --run-tests
> fit_image.FitImage`
> 7. Verify that is successfully: PASS
> ```
> 2020-05-26 16:54:34,996 - oe-selftest - INFO - SUMMARY:
> 2020-05-26 16:54:34,996 - oe-selftest - INFO - oe-selftest () -
> Ran 13
> tests in 1956.639s
> 2020-05-26 16:54:34,997 - oe-selftest - INFO - oe-selftest - OK -
> All
> required tests passed (successes=13, skipped=0, failures=0,
> errors=0)
> ``` 
>  
> 
> Changes since v1:
> 
> - Change the format of short-log to ": "
> 
> Changes since v2:
> 
> - rename the file from `fit-image` to `fit_image` to successfully
> export the class functions.
> - adding new sanity checks.
> - add missing dependency.
> - fix a variable reference in a debug log.
> 
> Changes since v3:
> 
> - unit-test added
> - class updated to support also properties for U-Boot image
> 
> Changes since v4:
> 
> - remove a wrong patch
> 
> Changes since v5:
> 
> - something went wrong with generation of the patches. regenerate
> 
> Changes since v6:
> 
> - fix the shortlog for one of the patches
> 
> Nandor Han (3):
>   python-fdt: add a recipe for `python3-fdt` package
>   classes: Add a new bbclass that abstracts the generation of FIT
> blobs
>   selftest: add a unit-test for fit-image bbclass
> 
>  .../fit-image-test/files/dt-fake.dtb  |   3 +
>  .../fit-image-test/files/zImage-fake  |   3 +
>  .../fit-image-test/fit-image-test.bb  |  17 +
>  meta/classes/fit_image.bbclass| 387
> ++
>  meta/lib/oeqa/selftest/cases/fit_image.py | 212 ++
>  .../python/python3-fdt_0.2.0.bb   |  14 +
>  6 files changed, 636 insertions(+)
>  create mode 100644 meta-selftest/recipes-test/fit-image-
> test/files/dt-fake.dtb
>  create mode 100644 meta-selftest/recipes-test/fit-image-
> test/files/zImage-fake
>  create mode 100644 meta-selftest/recipes-test/fit-image-test/fit-
> image-test.bb
>  create mode 100644 meta/classes/fit_image.bbclass
>  create mode 100644 meta/lib/oeqa/selftest/cases/fit_image.py
>  create mode 100644 meta/recipes-devtools/python/python3-fdt_0.2.0.bb

This did show up two issues in testing:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1022

(step2d)

Basically there is no maintainer listed for python3-fdt which is an
easy fix and secondly the tests need python3-fdt-native which isn't
present in the test environment.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139247): 
https://lists.openembedded.org/g/openembedded-core/message/139247
Mute This Topic: https://lists.openembedded.org/mt/74494471/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Stable Warrior branch

[akuster]

Hello,

The Warrior branch of Poky has had its last official dot release. It
will be moving to Community support and EOL within 6 weeks if no one
steps up.
If someone is interested in taking on the responsibilities of
maintaining the "Warrior" branch moving forward, please email this list.

Please look at the
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS for what will
be expected.

regards,
Armin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139246): 
https://lists.openembedded.org/g/openembedded-core/message/139246
Mute This Topic: https://lists.openembedded.org/mt/74687063/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] Revert "vim: do not adjust script paths building for target"

[Chen Qi]

This reverts commit 8972fe5581b9fe8ef14d539001758bb13bca6737.

The above commit causes regression when vim-tools is installed.
The error is like below.

Error:
 Problem: conflicting requests
   - nothing provides /bin/csh needed by vim-tools-8.2-r0.corei7_64
   - nothing provides /usr/bin/nawk needed by vim-tools-8.2-r0.corei7_64
   - nothing provides /usr/bin/python needed by vim-tools-8.2-r0.corei7_64

Signed-off-by: Chen Qi 
---
 .../vim/files/no-path-adjust.patch| 27 ---
 meta/recipes-support/vim/vim.inc  | 12 -
 2 files changed, 6 insertions(+), 33 deletions(-)
 delete mode 100644 meta/recipes-support/vim/files/no-path-adjust.patch

diff --git a/meta/recipes-support/vim/files/no-path-adjust.patch 
b/meta/recipes-support/vim/files/no-path-adjust.patch
deleted file mode 100644
index 05c2d803f6..00
--- a/meta/recipes-support/vim/files/no-path-adjust.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-vim: do not adjust script pathnames
-
-When cross-compiling, we do not want to reference the host versions of
-things like perl and awk.
-
-Upstream-Status: Pending
-
-Signed-off-by: Joe Slater 
-
 a/src/Makefile
-+++ b/src/Makefile
-@@ -2507,11 +2507,14 @@ installtools: $(TOOLS) $(DESTDIR)$(exec_
-rm -rf $$cvs; \
- fi
-   -chmod $(FILEMOD) $(DEST_TOOLS)/*
--# replace the path in some tools
-+
-+# replace the path in some tools, but not when cross-compiling
-+ifneq ($(CROSS_COMPILING),1)
-   perlpath=`./which.sh perl` && sed -e "s+/usr/bin/perl+$$perlpath+" 
$(TOOLSSOURCE)/efm_perl.pl >$(DEST_TOOLS)/efm_perl.pl
-   awkpath=`./which.sh nawk` && sed -e "s+/usr/bin/nawk+$$awkpath+" 
$(TOOLSSOURCE)/mve.awk >$(DEST_TOOLS)/mve.awk; if test -z "$$awkpath"; then \
-   awkpath=`./which.sh gawk` && sed -e 
"s+/usr/bin/nawk+$$awkpath+" $(TOOLSSOURCE)/mve.awk >$(DEST_TOOLS)/mve.awk; if 
test -z "$$awkpath"; then \
-   awkpath=`./which.sh awk` && sed -e "s+/usr/bin/nawk+$$awkpath+" 
$(TOOLSSOURCE)/mve.awk >$(DEST_TOOLS)/mve.awk; fi; fi
-+endif
-   -chmod $(SCRIPTMOD) `grep -l "^#!" $(DEST_TOOLS)/*`
- 
- # install the language specific files for tools, if they were unpacked
diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index 9f3dc08027..78e3f9528d 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -11,7 +11,6 @@ SRC_URI = "git://github.com/vim/vim.git \
file://disable_acl_header_check.patch \
file://vim-add-knob-whether-elf.h-are-checked.patch \
file://0001-src-Makefile-improve-reproducibility.patch \
-   file://no-path-adjust.patch \
 "
 SRCREV = "98056533b96b6b5d8849641de93185dd7bcadc44"
 
@@ -83,6 +82,12 @@ EXTRA_OECONF = " \
 do_install() {
 autotools_do_install
 
+# Work around file-rdeps picking up csh, awk, perl or python as a dep
+chmod -x ${D}${datadir}/${BPN}/${VIMDIR}/tools/vim132
+chmod -x ${D}${datadir}/${BPN}/${VIMDIR}/tools/mve.awk
+chmod -x ${D}${datadir}/${BPN}/${VIMDIR}/tools/*.pl
+chmod -x ${D}${datadir}/${BPN}/${VIMDIR}/tools/*.py
+
 # Install example vimrc from runtime files
 install -m 0644 runtime/vimrc_example.vim ${D}/${datadir}/${BPN}/vimrc
 
@@ -105,12 +110,7 @@ FILES_${PN}-help = "${datadir}/${BPN}/${VIMDIR}/doc"
 FILES_${PN}-tutor = "${datadir}/${BPN}/${VIMDIR}/tutor ${bindir}/${BPN}tutor"
 FILES_${PN}-vimrc = "${datadir}/${BPN}/vimrc"
 FILES_${PN}-data = "${datadir}/${BPN}"
-
-# We do not want to complain if perl or gawk are not on the target.
-#
 FILES_${PN}-tools = "${datadir}/${BPN}/${VIMDIR}/tools"
-INSANE_SKIP_${PN}-tools = "file-rdeps"
-
 FILES_${PN}-common = " \
 ${datadir}/${BPN}/${VIMDIR}/*.vim \
 ${datadir}/${BPN}/${VIMDIR}/autoload \
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139245): 
https://lists.openembedded.org/g/openembedded-core/message/139245
Mute This Topic: https://lists.openembedded.org/mt/74685328/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] db: enable verify PACKAGECONFIG

[Chen Qi]

On 06/03/2020 04:40 PM, Richard Purdie wrote:

On Wed, 2020-06-03 at 13:48 +0800, Chen Qi wrote:

On target, when running `db_verify /var/lib/rpm/Packages', we get
the following error.

   db_verify: BDB0571 library build did not include support for database 
verification

Enable the 'verify' PACKAGECONFIG to avoid such issue.

Signed-off-by: Chen Qi 
---
  meta/recipes-support/db/db_5.3.28.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/db/db_5.3.28.bb 
b/meta/recipes-support/db/db_5.3.28.bb
index 3a0923ae36..b64c4c089a 100644
--- a/meta/recipes-support/db/db_5.3.28.bb
+++ b/meta/recipes-support/db/db_5.3.28.bb
@@ -61,7 +61,7 @@ DB5_CONFIG ?= "--enable-o_direct --disable-cryptography 
--disable-queue --disabl
  
  EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot STRIP=true"
  
-PACKAGECONFIG ??= ""

+PACKAGECONFIG ??= "verify"
  PACKAGECONFIG[verify] = "--enable-verify, --disable-verify"
  PACKAGECONFIG[dbm] = "--enable-dbm,--disable-dbm,"

Do we ever need to run this on target? I'm wondering why we need this
and what the implications are (extra size to the binaries?). Perhaps we
just shouldn't ship that binary if verify isn't enabled?

Cheers,

Richard



Thanks. I've sent out a new patch.

Regards,

Chen Qi

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139244): 
https://lists.openembedded.org/g/openembedded-core/message/139244
Mute This Topic: https://lists.openembedded.org/mt/74644508/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] db: do not install db_verify if 'verify' is not enabled

[Chen Qi]

On target, when running `db_verify /var/lib/rpm/Packages', we get
the following error.

  db_verify: BDB0571 library build did not include support for database 
verification

This is because db_verify is installed but 'verify' PACKAGECONFIG is
not enabled. So fix it by not installing do_verify in such case.

Signed-off-by: Chen Qi 
---
 meta/recipes-support/db/db_5.3.28.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-support/db/db_5.3.28.bb 
b/meta/recipes-support/db/db_5.3.28.bb
index 3a0923ae36..318efcb61d 100644
--- a/meta/recipes-support/db/db_5.3.28.bb
+++ b/meta/recipes-support/db/db_5.3.28.bb
@@ -109,6 +109,9 @@ do_install_append() {
fi
 
chown -R root:root ${D}
+   if ${@bb.utils.contains('PACKAGECONFIG', 'verify', 'false', 'true', 
d)}; then
+   rm -f ${D}${bindir}/db_verify
+   fi
 }
 
 INSANE_SKIP_${PN} = "dev-so"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139243): 
https://lists.openembedded.org/g/openembedded-core/message/139243
Mute This Topic: https://lists.openembedded.org/mt/74685258/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for patch.py: don't apply striplevel to git am command

[Patchwork]

== Series Details ==

Series: patch.py: don't apply striplevel to git am command
Revision: 1
URL   : https://patchwork.openembedded.org/series/24491/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[v2,1/1] patch.py: don't apply striplevel to git am command
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")

* Issue A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence] 
  Suggested fixSign off the added patch file 
(meta-selftest/recipes-test/llvm/files/0001-Test-new-file.patch)

* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta-selftest/recipes-test/llvm/files/0001-Test-new-file.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139242): 
https://lists.openembedded.org/g/openembedded-core/message/139242
Mute This Topic: https://lists.openembedded.org/mt/74685155/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 1/1] patch.py: don't apply striplevel to git am command

[bkylerussell]

Don't pass a path removal parameter to git am since it always applies
patches from the root of the git repo, not from each individual patchdir
(like quilt).

GitApplyTree uses `git rev-parse --show-toplevel` to find the root of
the repo no matter which patchdir is passed into the GitApplyTree instance.
But for recipes who set S to a subdirectory within their repo, patches
may be added to SRC_URI using a striplevel parameter to match the depth of S.

Currently when these patches are applied with git am in GitApplyTree instead
of quilt, the striplevel still takes effect even though git applies the
patch itself from the repo root, not from within S.

In most cases when a patch modifies existing files within a repo, git am
works fine and the desired outcome is still achieved because the three-way
merge figures out which file the patch was intended to modify based on the
repo history.

An exception to this occurs if the patch adds a new file to the repo.

For example, consider a patch that adds a new file src/foo to a repo.
Additionally, assume the recipe for this repo sets S = "${WORKDIR}/git/src",
and the patch is added to SRC_URI using "striplevel=2" since the default
patch tool, quilt, applies each patch at its patchdir, ${S}.

  --- /dev/null
  +++ b/src/foo
  @@ -0,0 +1 @@
  +new file test

When the GitApplyTree patch class is used (through either devtool or
PATCHTOOL = "git"), the root of the repo is passed to git as the work tree,
in addition to the path removal paramter.  In the case above, GitApplyTree
creates ${WORKDIR}/git/foo instead of ${WORKDIR}/git/src/foo.

This is demonstrated with the included selftest.  By not passing the striplevel
parameter to git am, the patch creates the new file at the intended depth in
the repo.
---
 .../llvm/files/0001-Test-new-file.patch| 17 +
 .../recipes-test/llvm/llvm_%.bbappend  |  2 ++
 meta/lib/oe/patch.py   |  2 +-
 meta/lib/oeqa/selftest/cases/bbtests.py| 18 ++
 4 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 
meta-selftest/recipes-test/llvm/files/0001-Test-new-file.patch
 create mode 100644 meta-selftest/recipes-test/llvm/llvm_%.bbappend

diff --git a/meta-selftest/recipes-test/llvm/files/0001-Test-new-file.patch 
b/meta-selftest/recipes-test/llvm/files/0001-Test-new-file.patch
new file mode 100644
index 00..8af0afeb12
--- /dev/null
+++ b/meta-selftest/recipes-test/llvm/files/0001-Test-new-file.patch
@@ -0,0 +1,17 @@
+From 057c3da44affb47c154ec1ef67bd11646a6429fa Mon Sep 17 00:00:00 2001
+From: Kyle Russell 
+Date: Tue, 28 Apr 2020 15:18:43 -0400
+Subject: [PATCH] Test new file
+
+---
+ llvm/README.new | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 llvm/README.new
+
+diff --git a/llvm/README.new b/llvm/README.new
+new file mode 100644
+index 000..0527e6bd2d7
+--- /dev/null
 b/llvm/README.new
+@@ -0,0 +1 @@
++This is a test
diff --git a/meta-selftest/recipes-test/llvm/llvm_%.bbappend 
b/meta-selftest/recipes-test/llvm/llvm_%.bbappend
new file mode 100644
index 00..205720982c
--- /dev/null
+++ b/meta-selftest/recipes-test/llvm/llvm_%.bbappend
@@ -0,0 +1,2 @@
+# This bbappend is used to alter the recipe using the test_recipe.inc file 
created by tests.
+include test_recipe.inc
diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index 7ca2e28b1f..870d183e8b 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -512,7 +512,7 @@ class GitApplyTree(PatchTree):
 try:
 shellcmd = [patchfilevar, "git", "--work-tree=%s" % reporoot]
 self.gitCommandUserOptions(shellcmd, self.commituser, 
self.commitemail)
-shellcmd += ["am", "-3", "--keep-cr", "-p%s" % 
patch['strippath']]
+shellcmd += ["am", "-3", "--keep-cr"]
 return _applypatchhelper(shellcmd, patch, force, reverse, run)
 except CmdError:
 # Need to abort the git am, or we'll still be within it at the 
end
diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py 
b/meta/lib/oeqa/selftest/cases/bbtests.py
index dc423ec439..6d863b425a 100644
--- a/meta/lib/oeqa/selftest/cases/bbtests.py
+++ b/meta/lib/oeqa/selftest/cases/bbtests.py
@@ -4,6 +4,7 @@
 
 import os
 import re
+import tempfile
 
 import oeqa.utils.ftools as ftools
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars
@@ -81,6 +82,23 @@ class BitbakeTests(OESelftestTestCase):
 found = l
 self.assertTrue(found and found.startswith("ERROR:"), msg = 
"Incorrectly formed patch application didn't fail. bitbake output: %s" % 
result.output)
 
+def test_patchtool_git(self):
+test_recipe = 'llvm'
+tmpdir = tempfile.mkdtemp(prefix='bitbakeqa')
+bb_vars = get_bb_vars(['S'], test_recipe)
+src_dir = bb_vars['S']
+
+self.write_recipeinc('llvm', 'FILESEXTRAPATHS_prepend := 
"${THISDIR}/files:"\nSRC_URI += "file://0001-

[OE-core] [PATCH v2 0/1] patch.py: don't apply striplevel to git am command

[bkylerussell]

I thought I had sent this out a month ago, but I can't find it in patchwork,
so I'm resending.  This is an updated patch that addresses feedback on v1, and
should hopefully be more clear.

I've dropped the change to 'git apply' since that wasn't behaving as I 
originally
thought, then I added a selftest on llvm that demonstrates the issue I'm trying 
to
resolve.  Without the change in patch.py included here, the selftest that I'm
proposing will fail.

One might argue, "Well, if you change the default PATCHTOOL, you could also
just change your patch SRC_URIs and drop the striplevel parameter."  While
that may be true, the same failure can also be demonstrated using devtool on
llvm without modifying PATCHTOOL at all, since by default devtool also uses
GitApplyTree.  So if you don't consider "modifying a recipe's PATCHTOOL without
also modify its SRC_URI patches" to be a valid workflow, devtool is another
common workflow where this behavior could be encountered.

Hope that helps,
Kyle

Kyle Russell (1):
  patch.py: don't apply striplevel to git am command

 .../llvm/files/0001-Test-new-file.patch| 17 +
 .../recipes-test/llvm/llvm_%.bbappend  |  2 ++
 meta/lib/oe/patch.py   |  2 +-
 meta/lib/oeqa/selftest/cases/bbtests.py| 18 ++
 4 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 
meta-selftest/recipes-test/llvm/files/0001-Test-new-file.patch
 create mode 100644 meta-selftest/recipes-test/llvm/llvm_%.bbappend

-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139240): 
https://lists.openembedded.org/g/openembedded-core/message/139240
Mute This Topic: https://lists.openembedded.org/mt/74684793/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] cairo: Do not try to remove nonexistent directories

[Khem Raj]

On 6/2/20 2:06 AM, Peter Kjellerstedt wrote:

Commit 0e1f8fa0 (bitbake.conf: propagate 'opengl' DISTRO_FEATURE to
native/nativesdk from target) changed the default PACKAGECONFIG for
native and nativesdk so that it becomes empty unless "x11" is in
DISTRO_FEATURES since "trace" was also removed (propbably
unintentionally). This highlighted than an empty PACKAGECONFIG would
lead to a build failure since /usr/bin is never created under these
conditions, but the recipe still tried to remove it.



looking at above commit, its doing
PACKAGECONFIG_class-native = "${@bb.utils.filter('DISTRO_FEATURES', 
'x11', d)}"
PACKAGECONFIG_class-nativesdk = "${@bb.utils.filter('DISTRO_FEATURES', 
'x11', d


there are cases where we build firmware's with and without x11 in distro
features, now we have another set of native and nativesdk packages to 
build. Scratch builds from release to release are getting longer and 
longer, using shared state hides the problem, but first build experience 
is quite not as good.



Signed-off-by: Peter Kjellerstedt 
---
  meta/recipes-graphics/cairo/cairo_1.16.0.bb | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/cairo/cairo_1.16.0.bb 
b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
index 092c77b826..195a66b37d 100644
--- a/meta/recipes-graphics/cairo/cairo_1.16.0.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
@@ -70,8 +70,10 @@ do_install_append () {
rm -rf ${D}${libdir}/cairo/cairo-sphinx*
rm -rf ${D}${libdir}/cairo/.debug/cairo-fdr*
rm -rf ${D}${libdir}/cairo/.debug/cairo-sphinx*
-   rmdir -p --ignore-fail-on-non-empty ${D}${bindir}
-   rmdir -p --ignore-fail-on-non-empty ${D}${libdir}/cairo
+   [ ! -d ${D}${bindir} ] ||
+   rmdir -p --ignore-fail-on-non-empty ${D}${bindir}
+   [ ! -d ${D}${libdir}/cairo ] ||
+   rmdir -p --ignore-fail-on-non-empty ${D}${libdir}/cairo
  }
  
  PACKAGES =+ "cairo-gobject cairo-script-interpreter cairo-perf-utils"





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139239): 
https://lists.openembedded.org/g/openembedded-core/message/139239
Mute This Topic: https://lists.openembedded.org/mt/74623912/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 65/70] libyaml: adjust license checksum to omit copyright year lines.

[Khem Raj]

Good catch Peter.

Checksum mismatch for copyright year may sound benign but we really need 
to know the changes even if its just copyright year change these

are recorded and part of license text, so its important in general to
keep this check strict like it is without this patch. So dropping this 
patch is right thing to do.


On 6/2/20 1:27 AM, Alexander Kanavin wrote:

Right, in that case this commit should indeed be dropped or reverted.

Alex

On Tue, 2 Jun 2020 at 09:39, Peter Kjellerstedt 
mailto:peter.kjellerst...@axis.com>> wrote:


If you have COPY_LIC_DIRSenabled, the license files (the ones listed
in LICENSEand the (parts) listed in LIC_FILES_CHKSUM) will be
included in the generated image by license_image.bbclass. Extraction
of the license information is handled by license.bbclass, which also
is responsible for creating ${PN}-lic packages if
LICENSE_CREATE_PACKAGEis set.

__ __

//Peter

__ __

*From:*Alexander Kanavin mailto:alex.kana...@gmail.com>>
*Sent:* den 2 juni 2020 09:30
*To:* Peter Kjellerstedt mailto:peter.kjellerst...@axis.com>>
*Cc:* openembedded-core@lists.openembedded.org

*Subject:* Re: [OE-core] [PATCH 65/70] libyaml: adjust license
checksum to omit copyright year lines.

__ __

On Tue, 2 Jun 2020 at 00:12, Peter Kjellerstedt
mailto:peter.kjellerst...@axis.com>>
wrote:

 > -Original Message-
 > From: openembedded-core@lists.openembedded.org
  c...@lists.openembedded.org
> On Behalf Of Alexander Kanavin
 > Sent: den 31 maj 2020 17:53
 > To: openembedded-core@lists.openembedded.org

 > Cc: Alexander Kanavin mailto:alex.kana...@gmail.com>>
 > Subject: [OE-core] [PATCH 65/70] libyaml: adjust license
checksum to omit
 > copyright year lines.

Eh, what? That's definitely not the right thing to do. For a
license
that says "The above copyright notice and this permission notice
shall
be included in all copies or substantial portions of the
Software.",
removing the copyright information makes the file useless as
part of,
e.g., ${PN}-lic.

__ __

As far as I understand, the extracts from LIC_FILES_CHKSUM are not
used in copies or substantial portions of the software,

they are used in tmp/deploy/licenses (which is neither). Is it
beneficial to have the copyright years and owners

there? The idea behind dropping them is that we can avoid continuous
adjusting of the checksum on version updates.

__ __

If you archive the source code, or install binaries to the target,
this mechanism is not involved.

__ __

I am not aware of ${PN}-lic, can you please point where that is
defined?

__ __

Alex




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139238): 
https://lists.openembedded.org/g/openembedded-core/message/139238
Mute This Topic: https://lists.openembedded.org/mt/74584232/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Steve Sakoman]

The following changes since commit c88cf750f26f6786d6ba5b4f1f7e5d4f0c800e6e:

  avahi: Don't advertise example services by default (2020-05-26 04:12:28 -1000)

are available in the Git repository at:

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

Adrian Bunk (1):
  libubootenv: Remove the DEPENDS on mtd-utils

Bruce Ashfield (8):
  linux-yocto/5.4: update to v5.4.38
  linux-yocto/5.4: update to v5.4.40
  kernel/reproducibility: kernel modules need SOURCE_DATE_EPOCH export
  linux-yocto/5.4: update to v5.4.42
  linux-yocto-rt/5.4: update to rt24
  linux-yocto/5.4: temporarily revert IKHEADERS in standard kernels
  linux-yocto: gather reproducibility configs into a fragment
  linux-yocto/5.4: update to v5.4.43

Gregor Zatko (1):
  sanity.bbclass: Detect and fail if 'inherit' is used in conf file

Joe Slater (1):
  terminal.py: do not stop searching for auto

Joshua Watt (6):
  checklayer: Skip layers without a collection
  pycryptodome: Import from meta-python
  pyelftools: Import from meta-python
  python3-pycryptodome(x): Upgrade 3.9.4 -> 3.9.7
  python3-pyelftools: Upgrade 0.25 -> 0.26
  layer.conf: Bump OE-Core layer version

Khem Raj (2):
  cve-check: Run it after do_fetch
  make-mod-scripts: Fix a rare build race condition

Konrad Weihmann (1):
  qemurunner: fix ip fallback detection

Lee Chee Yang (2):
  bind: fix CVE-2020-8616/7
  libexif: fix CVE-2020-13114

Mark Hatle (1):
  sstate.bbclass: When siginfo or sig files are missing, stop fetcher
errors

Richard Purdie (2):
  resulttool/report: Remove leftover debugging
  resulttool/log: Add ability to dump ltp logs as well as ptest

Robert Yang (1):
  archiver.bbclass: Fix duplicated SRC_URIs for do_ar_original

Steve Sakoman (1):
  oeqa/concurrencytest: don't delete build directory for failed tests

Trevor Gamblin (1):
  qemuarm: check serial consoles vs /proc/consoles

 meta/classes/archiver.bbclass |   8 +-
 meta/classes/cve-check.bbclass|   2 +-
 meta/classes/kernel.bbclass   |  15 ++
 meta/classes/sanity.bbclass   |   6 +
 meta/classes/sstate.bbclass   |   6 +-
 meta/conf/distro/include/maintainers.inc  |   5 +-
 meta/conf/layer.conf  |   2 +-
 meta/conf/machine/qemuarm.conf|   1 +
 meta/conf/machine/qemuarm64.conf  |   1 +
 meta/lib/oe/terminal.py   |   5 +-
 meta/lib/oeqa/core/utils/concurrencytest.py   |  10 +-
 meta/lib/oeqa/utils/qemurunner.py |   2 +-
 meta/recipes-bsp/u-boot/libubootenv_0.2.bb|   2 +-
 .../bind/bind/CVE-2020-8616.patch | 206 ++
 .../bind/bind/CVE-2020-8617.patch |  29 +++
 .../recipes-connectivity/bind/bind_9.11.13.bb |   2 +
 .../python/python-pycryptodome.inc|  26 +++
 .../python/python3-pycryptodome_3.9.7.bb  |   5 +
 .../python/python3-pycryptodomex_3.9.7.bb |   9 +
 .../python/python3-pyelftools_0.26.bb |  14 ++
 .../linux/linux-yocto-rt_5.4.bb   |   6 +-
 .../linux/linux-yocto-tiny_5.4.bb |   8 +-
 meta/recipes-kernel/linux/linux-yocto_5.4.bb  |  22 +-
 .../make-mod-scripts/make-mod-scripts_1.0.bb  |   7 +-
 .../libexif/libexif/CVE-2020-13114.patch  |  73 +++
 .../recipes-support/libexif/libexif_0.6.21.bb |   4 +-
 scripts/lib/checklayer/__init__.py|   3 +
 scripts/lib/resulttool/log.py |  21 +-
 scripts/lib/resulttool/report.py  |   1 -
 scripts/lib/resulttool/resultutils.py |  22 +-
 30 files changed, 475 insertions(+), 48 deletions(-)
 create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2020-8616.patch
 create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2020-8617.patch
 create mode 100644 meta/recipes-devtools/python/python-pycryptodome.inc
 create mode 100644 meta/recipes-devtools/python/python3-pycryptodome_3.9.7.bb
 create mode 100644 meta/recipes-devtools/python/python3-pycryptodomex_3.9.7.bb
 create mode 100644 meta/recipes-devtools/python/python3-pyelftools_0.26.bb
 create mode 100644 meta/recipes-support/libexif/libexif/CVE-2020-13114.patch

-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139237): 
https://lists.openembedded.org/g/openembedded-core/message/139237
Mute This Topic: https://lists.openembedded.org/mt/74683525/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH

[Khem Raj]

On Thu, Jun 4, 2020 at 1:30 AM Richard Purdie
 wrote:
>
> On Fri, 2020-05-22 at 00:23 +, Mittal, Anuj wrote:
> > On Thu, 2020-05-21 at 17:05 -0700, Khem Raj wrote:
> > > On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj  > > >
> > > wrote:
> > > > On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote:
> > > > > On Thu, May 21, 2020 at 6:16 PM Khem Raj 
> > > > > wrote:
> > > > > > Now that they uses -mcpu, its better to have tune specific
> > > > > > build
> > > > > > directories, since aarch64 wont be appropriate any longer
> > > > >
> > > > > I agree with Steve that this is a bit invasive for stable
> > > > > branch,
> > > > > but
> > > > > on the other hand it's long overdue and if we don't improve it
> > > > > in
> > > > > LTS
> > > > > branch then many people will need to carry local work arounds
> > > > > for
> > > > > multi-machine builds. +1 from me.
> > > > >
> > > >
> > > > But this is against the LTS/Stable branch policy. What is the
> > > > point
> > > > of
> > > > having a policy if we are going to keep making exceptions?
> > > > There'd
> > > > be
> > > > other changes as well for which people might be carrying work-
> > > > arounds.
> > > > Would we be willing to make exceptions for all?
> > > >
> > >
> > > Thanks for bringing this up. Policy exceptions are not common but
> > > they
> >
> > That's two exceptions in a week.
> >
> > I am not against the change but I think the policy document should be
> > modified to define how exceptions should/will be handled.
> >
> > > are not absent either
> > > hence context is important for such changes, I am definitely
> > > interested to hear
> > > about how it is going to affect arm64 users at this early stage of
> > > release.
> >
> > The release has been made and I think the branch is assumed to be
> > stable from the time it was released and policy should be applied?
> > There's no early release stage defined where-in such changes would be
> > acceptable.
>
> This series doesn't have a decision on it yet. If an exception were
> made, it would be two exceptions in the lifetime of the LTS so far, not
> just a week. The fact we'd like to make a point release is focusing the
> fact we need to make some decisions rather than a sudden stream of
> policy exceptions.
>
> I'd also note its most likely we'd find issues just after release as
> people start using things, over time it becomes much less likely.
>
> If such issues are identified, particularly now as people start using
> it, the question is what we do about it. If we can fix things to
> improve things for users and the risk is either low, or managed to a
> specific subset of users who can benefit, that does seem like a
> sensible thing to do.
>
> I guess I'd hoped we could all be sensible about these things, the LTS
> policy is there as a set of 'guide rails' to make decisions against but
> as a maintainer, I know that not everything that makes sense neatly
> fits within a written set of rules. The LTS maintainer does need to
> have some ability to make decisions and I've always thought it was
> clear the TSCs are the ultimate decision makers for any technical
> decision the project faces should there not be consensus.

downstream distros will require such things for supporting their products,
in past it was done on their chosen release and they stayed with that
release with their own delta, the hope is that they will use LTS and just from
LTS to LTS in product cycles. IMO LTS will have to considerate to
this fact, if we do not want downstream distros to diverge significantly
and if we want to put hard conditions early on release then I guess
users will have to devise their own plans regardless of LTS.
e.g. See the delta between ubuntu
LTS first point release ( 20.04 and 20.04.1 ), most users wait for first point
release to migrate to next LTS there is a reason for that.
There is quite a bit of stabilization that happens
early on in LTS life.

>
> In the case of these patches I'm not seeing anyone arguing against them
> on technical grounds or saying they don't make sense other than some
> things I've said to Steve! The complaint is that they break policy.
>
> I will discuss making a escalation and final decision path clearer with
> the YP TSC (who wrote/maintain the policy).
>
> Cheers,
>
> Richard
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139236): 
https://lists.openembedded.org/g/openembedded-core/message/139236
Mute This Topic: https://lists.openembedded.org/mt/74379085/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH

[Khem Raj]

On Thu, May 21, 2020 at 5:23 PM Mittal, Anuj  wrote:
>
> On Thu, 2020-05-21 at 17:05 -0700, Khem Raj wrote:
> > On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj 
> > wrote:
> > > On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote:
> > > > On Thu, May 21, 2020 at 6:16 PM Khem Raj 
> > > > wrote:
> > > > > Now that they uses -mcpu, its better to have tune specific
> > > > > build
> > > > > directories, since aarch64 wont be appropriate any longer
> > > >
> > > > I agree with Steve that this is a bit invasive for stable branch,
> > > > but
> > > > on the other hand it's long overdue and if we don't improve it in
> > > > LTS
> > > > branch then many people will need to carry local work arounds for
> > > > multi-machine builds. +1 from me.
> > > >
> > >
> > > But this is against the LTS/Stable branch policy. What is the point
> > > of
> > > having a policy if we are going to keep making exceptions? There'd
> > > be
> > > other changes as well for which people might be carrying work-
> > > arounds.
> > > Would we be willing to make exceptions for all?
> > >
> >
> > Thanks for bringing this up. Policy exceptions are not common but
> > they
>
> That's two exceptions in a week.
>
> I am not against the change but I think the policy document should be
> modified to define how exceptions should/will be handled.
>
> > are not absent either
> > hence context is important for such changes, I am definitely
> > interested to hear
> > about how it is going to affect arm64 users at this early stage of
> > release.
>
> The release has been made and I think the branch is assumed to be
> stable from the time it was released and policy should be applied?
> There's no early release stage defined where-in such changes would be
> acceptable.

we do have QA qualification criteria for releases and LTS is no different for
meeting that requirement. so these patches if regressing should be
found out before
point release.
LTS has to be useful for new SOCs and with the least amount of
patching, I am yet
to hear technical downsides or concerns for this patchset. I have no problem
in maintaining them in the downstream distro since they are already in master it
really is fine since they will be in the next LTS and we will be fine.
I was hoping the
experience better for others and have a bit of fewer patches to maintain.

>
> Thanks,
>
> Anuj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139235): 
https://lists.openembedded.org/g/openembedded-core/message/139235
Mute This Topic: https://lists.openembedded.org/mt/74379085/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v3] glibc: move ld.so.conf back to main package

[Phil Blundell via lists.openembedded.org]

On Thu, Jun 04, 2020 at 01:05:30PM -0700, Andre McCurdy wrote:
> The fix being proposed is simply to always leave the config file in
> the rootfs, so it's always there when ldconfig is run at build time.
> Doing so seems safe enough. Since the config file is only parsed by
> ldconfig, there's no run time performance penalty of leaving it around
> - it will just be ignored if there's no ldconfig in the rootfs to use
> it.

Yes, agreed.  For some reason I had previously got it into my head
that ld.so itself would read ld.so.conf if there is no ld.so.cache,
but I just checked the glibc sources again and clearly it doesn't.
I'm not sure if my previous understanding was outdated, mixed up
with some other libc, or just plain wrong, but either way you're
right that there's no performance penalty.

I also checked with strace which reveals that, on the other hand,
ld.so _is_ trying to open /etc/ld.so.preload which is clearly a
waste of time as well.  But that's a separate issue...

p.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139234): 
https://lists.openembedded.org/g/openembedded-core/message/139234
Mute This Topic: https://lists.openembedded.org/mt/74625854/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH v3 4/8] bitbake: lib: Add PrefixLoggerAdapter helper

[Richard Purdie]

On Tue, 2020-06-02 at 21:54 -0500, Joshua Watt wrote:
> Adds a helper logger adapter to add a prefix to all log messages.
> This
> is useful to distinguish log messages between multiple instances of a
> object.
> 
> Signed-off-by: Joshua Watt 
> ---
>  bitbake/lib/bb/__init__.py | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/bitbake/lib/bb/__init__.py b/bitbake/lib/bb/__init__.py
> index 2e2966c3b9..1de32041ed 100644
> --- a/bitbake/lib/bb/__init__.py
> +++ b/bitbake/lib/bb/__init__.py
> @@ -84,6 +84,14 @@ logger.setLevel(logging.DEBUG - 2)
>  
>  mainlogger = logging.getLogger("BitBake.Main")
>  
> +class PrefixLoggerAdapter(logging.LoggerAdapter):
> +def __init__(self, prefix, logger):
> +super().__init__(logger, {})
> +self.__msg_prefix = prefix
> +
> +def process(self, msg, kwargs):
> +return "%s%s" %(self.__msg_prefix, msg), kwargs
> +

Ignoring the mailing list issue, I think there is something odd going
on with different python versions somewhere in here.

https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/1004
https://autobuilder.yoctoproject.org/typhoon/#/builders/107/builds/585
https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/2255
(all debian9)

and then selftest issues:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1020

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139233): 
https://lists.openembedded.org/g/openembedded-core/message/139233
Mute This Topic: https://lists.openembedded.org/mt/74642912/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v3] bzip2: Add test suite for bzip2

[Richard Purdie]

On Sun, 2020-05-31 at 17:57 +0530, Rahul Kumar wrote:
> Source: git://sourceware.org/git/bzip2-tests.git
> Type: Enhancement
> Description:
> bzip2 now has a test suite available at
> git://sourceware.org/git/bzip2-tests.git.
> 
> This is a collection of "interesting" .bz2 files that can be used to
> test bzip2 works correctly. They come from different projects.
> 
> Some files are deliberately bad, and are use to see how bzip2 handles
> corrupt files. They are explicitly not intended to decompress
> correctly,
> but to catch errors in bzip2 trying to deal with deliberately bad
> data.
> All such files have a name ending in .bz2.bad.
> 
> All non-bad files end in bz2. And should come with a .md5 file for
> the original input file. The .md5 file is used to check that bzip2
> could correctly decompress the file. The original (non-compressed)
> files are deliberately not checked in.
> 
> It will by default test with the command 'bzip2', running under
> valgrind (if installed on the system).
> 
> For each .bz2 file found it is decompressed, recompressed and
> decompressed again. Once with the default bzip2 settings and
> once in --small (-s) mode.
> 
> For each .bz2.bad file decompression is tried twice also. In
> default mode and small mode. The bzip2 binary is expected to
> return either 1 or 2 as exit status. Any other exit code is
> interpreted as failure.
> 
> License:
>In bzip2-tests source code Each directory should contain a README
>file explaining where the .bz2 files originally came from.
>Plus a reference to the (Free Software) license that the project
>files were distributed under.
> 
> Test Summery:
>On qemux86-64/kvm the ptest results with extra filesystem space
> (atleast 114688) are:
> 
> TOTAL:  396
> PASS:   396
> SKIP:   0
> XFAIL:  0
> FAIL:   0
> XPASS:  0
> ERROR:  0
> 
> All tests passed
> DURATION: 517
> 
> [YOCTO #13444]
> 
> Signed-off-by: Rahul Kumar 

Still not quite there yet unfortunately:

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1996
https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/1992
and probably a few other builds too.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139232): 
https://lists.openembedded.org/g/openembedded-core/message/139232
Mute This Topic: https://lists.openembedded.org/mt/74580690/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v3] glibc: move ld.so.conf back to main package

[Andre McCurdy]

On Thu, Jun 4, 2020 at 5:43 AM Richard Purdie
 wrote:
> On Wed, 2020-06-03 at 13:44 -0700, Andre McCurdy wrote:
> > On Wed, Jun 3, 2020 at 12:38 AM Rasmus Villemoes
> >  wrote:
> > > On 02/06/2020 23.46, Andre McCurdy wrote:
> > > > On Tue, Jun 2, 2020 at 2:15 PM Phil Blundell via
> > > > lists.openembedded.org 
> > > > wrote:
> > > > > On Tue, Jun 02, 2020 at 09:17:44PM +0100, Richard Purdie wrote:
> > > > > > I understand the concern, I am a little torn on this as
> > > > > > adding in too
> > > > > > many different controls and options complicates the test
> > > > > > matrix and
> > > > > > makes things harder for users.
> > > > > >
> > > > > > You're effectively suggesting a new DISTRO_FEATURE to control
> > > > > > this? or
> > > > > > maybe better, perhaps a glibc PACKAGECONFIG?
> > > > >
> > > > > Yes, right.  I don't think it need be a DISTRO_FEATURE because
> > > > > nothing
> > > > > outside glibc needs to care.
> > > > >
> > > > > Here are the scenarios that I think matter, ordered from
> > > > > simplest to
> > > > > most complex:
> > > > >
> > > > > 1. Immutable filesystem, every library installed in the place
> > > > > where
> > > > > ld.so would first look for it anyway (i.e. everything in
> > > > > {/usr}/lib).
> > > > > In this case, we don't want ldconfig (because it can never do
> > > > > anything
> > > > > useful), we don't want ld.so.cache and we don't want ld.so.conf
> > > > > because they would cause ld.so to do extra file loads and
> > > > > computation
> > > > > but end up with the same result that it would anyway.
> > > > >
> > > > > 2. Immutable filesystem but some libraries are in places that
> > > > > ld.so
> > > > > wouldn't automatically know about.  In this case we do want
> > > > > ld.so.conf
> > > > > and ld.so.cache, but we still don't want ldconfig.
> > > > >
> > > > > 3. Mutable filesystem where arbitrary binaries can be installed
> > > > > in
> > > > > arbitrary places.  It's probably debatable whether ldconfig is
> > > > > needed
> > > > > in all these cases, but clearly it's needed in some and I think
> > > > > at
> > > > > this point it can be left to a DISTRO decision how exactly they
> > > > > want
> > > > > to optimize things.
> > > > >
> > > > > I think right now oe-core supports #1 and #3.  The proposed
> > > > > patch
> > > > > seems to be aimed at #2, which is a completely valid usecase,
> > > >
> > > > It seems like a weird corner case to me. Where do these libraries
> > > > come
> > > > from and why can't they be moved or symlinked into a standard
> > > > path?
> > >
> > > Pre-compiled proprietary binaries/libraries that go in
> > > /opt//..., just as /opt is meant for (and no, we can't just
> > > install them to /usr/lib, /usr/bin etc - partly because they
> > > contain
> > > hard-coded absolute paths, but also due to some not-entirely-
> > > techical
> > > reasons). So there's an /etc/ld.so.conf.d/.conf that needs
> > > to be
> > > picked up.
> > >
> > > > If they are somehow special and only used by special applications
> > > > then
> > > > setting rpath or using LD_LIBRARY_PATH just for those
> > > > applications
> > > > would seem to be a better solution than enabling them globally.
> > >
> > > We don't control the compilation, so rpath is out. We did consider
> > > LD_LIBRARY_PATH, but figured that the ld.conf solution is more
> > > robust
> > > (no problems with setuid binaries or an application that
> > > misguidedly
> > > sanitizes the environment for subprocesses).
> >
> > Unless the supplier of your binaries is completely unresponsive (if
> > so, bad luck) then educating them on the usage of rpath and asking
> > for
> > a new release is probably the cleanest solution.
> >
> > If you start your special application via a wrapper script which sets
> > LD_LIBRARY_PATH then it won't be seen by anything else, so the
> > concerns about other apps messing with it etc should not apply?
> >
> > Relying on /etc/ld.so.conf.d/*.conf will certainly work too, but has
> > two disadvantages: it will add the custom library path globally
> > instead of just for the special apps and it's not portable (it's not
> > supported by musl etc - although if you only care about your
> > proprietary binaries pre-compiled for glibc then that won't matter to
> > you).
> >
> > Anyway, the original patch has been merged, so this now just a side
> > discussion.
>
> It hasn't, its still in master-next waiting for us to reach a
> conclusion...

OK. The discussion has moved on to the details of Rasmus's use case,
but I can try to summarise the details related to the actual patch...

The patch fixes the problem that if the ldconfig distro feature is
disabled, then the config file needed by ldconfig will not be present
in the rootfs when ldconfig is run at build time (and so ld.so.cache
may not be correctly generated). The change to move ldconfig and its
config file into a separate package didn't account for the fact that
the config file is used at build time, but the underlying proble

Re: [OE-core][PATCH v4 1/2] initscripts/init-system-helpers: fix mountnfs.sh dependency

[Denys Dmytriyenko]

On Tue, Jun 02, 2020 at 03:42:55PM +0200, Jens Rehsack wrote:
> With commit c9fc9110be33fe0f24bc3a7c242b584a4ca33e04
> Author: Yue Tao 
> Date:   Fri May 25 10:48:08 2018 +0800
> 
>   initscripts: Avoid starting rpcbind daemon twice
> 
>   Check the status before start it to avoid duplicates.
> 
> the use of a script {/usr/sbin/}service is introduced - maybe earlier
> provided by systemd, nowadays mostly by init-system-helpers from
> debian project.
> 
> For the very first shot, maybe discussions and improvements based
> on that script collection, use just the init-system-helpers-service
> in initscripts/mountnfs.sh to avoid problems mounting NFS in later
> boot stage.
> 
> Signed-off-by: Jens Rehsack 
> ---
>  meta/conf/distro/include/maintainers.inc  |  1 +
>  .../initscripts/init-system-helpers_1.57.bb   | 46 +++
>  .../initscripts/initscripts_1.0.bb|  1 +
>  3 files changed, 48 insertions(+)
>  create mode 100644 meta/recipes-core/initscripts/init-system-helpers_1.57.bb
> 
> diff --git a/meta/conf/distro/include/maintainers.inc 
> b/meta/conf/distro/include/maintainers.inc
> index 51e6da669c..adac9fd824 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -265,6 +265,7 @@ RECIPE_MAINTAINER_pn-icu = "Alexander Kanavin 
> "
>  RECIPE_MAINTAINER_pn-ifupdown = "Anuj Mittal "
>  RECIPE_MAINTAINER_pn-inetutils = "Tom Rini "
>  RECIPE_MAINTAINER_pn-init-ifupdown = "Anuj Mittal "
> +RECIPE_MAINTAINER_pn-init-system-helpers = "Anuj Mittal 
> "
>  RECIPE_MAINTAINER_pn-initramfs-boot = "Otavio Salvador 
> "
>  RECIPE_MAINTAINER_pn-initramfs-framework = "Otavio Salvador 
> "
>  RECIPE_MAINTAINER_pn-initramfs-live-boot = "Anuj Mittal 
> "
> diff --git a/meta/recipes-core/initscripts/init-system-helpers_1.57.bb 
> b/meta/recipes-core/initscripts/init-system-helpers_1.57.bb
> new file mode 100644
> index 00..d41bb94791
> --- /dev/null
> +++ b/meta/recipes-core/initscripts/init-system-helpers_1.57.bb
> @@ -0,0 +1,46 @@
> +SUMMARY = "helper tools for all init systems"
> +DESCRIPTION = "This package contains helper tools that are necessary for 
> switching between \
> +the various init systems that Debian contains (e. g. sysvinit or \
> +systemd). An example is deb-systemd-helper, a script that enables systemd 
> unit \
> +files without depending on a running systemd. \
> +\
> +It also includes the \"service\", \"invoke-rc.d\", and \"update-rc.d\" 
> scripts which \
> +provide an abstraction for enabling, disabling, starting, and stopping \
> +services for all supported Debian init systems as specified by the policy. \
> +\
> +While this package is maintained by pkg-systemd-maintainers, it is NOT \
> +specific to systemd at all. Maintainers of other init systems are welcome to 
> \
> +include their helpers in this package."
> +HOMEPAGE = "https://salsa.debian.org/debian/init-system-helpers";
> +SECTION = "base"
> +LICENSE = "BSD-3-Clause & GPLv2"
> +LIC_FILES_CHKSUM = 
> "file://debian/copyright;md5=ee2b1830fcfead84d07bc060ec43e072"
> +
> +DEPENDS = "perl"
> +
> +SRCREV = "760c625ec0e1ffebec2e391d891d389da0f65726"
> +SRC_URI = "git://salsa.debian.org/debian/init-system-helpers.git"

I'm getting this:

WARNING: init-system-helpers-1.57-r0 do_fetch: Failed to fetch URL 
git://salsa.debian.org/debian/init-system-helpers.git, attempting MIRRORS if 
available


> +
> +S = "${WORKDIR}/git"
> +
> +do_configure[noexec] = "1"
> +do_compile[noexec] = "1"
> +
> +do_install() {
> + install -d -m 0755 ${D}${sbindir}
> + install -m 0755 ${S}/script/invoke-rc.d ${D}${sbindir}
> + install -m 0755 ${S}/script/service ${D}${sbindir}
> + install -m 0755 ${S}/script/update-rc.d ${D}${sbindir}
> +}
> +
> +PACKAGES += "${PN}-invoke-rc.d ${PN}-service ${PN}-update-rc.d"
> +
> +FILES_${PN} = ""
> +FILES_${PN}-invoke-rc.d = "${sbindir}/invoke-rc.d"
> +FILES_${PN}-service = "${sbindir}/service"
> +FILES_${PN}-update-rc.d = "${sbindir}/update-rc.d"
> +
> +ALLOW_EMPTY_${PN} = "1"
> +
> +RDEPENDS_${PN}-update-rc.d = "perl"
> +RRECOMMENDS_${PN} += "${PN}-invoke-rc.d ${PN}-service ${PN}-update-rc.d"
> diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb 
> b/meta/recipes-core/initscripts/initscripts_1.0.bb
> index 1a59b82fbf..4080c4a495 100644
> --- a/meta/recipes-core/initscripts/initscripts_1.0.bb
> +++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
> @@ -50,6 +50,7 @@ PACKAGE_WRITE_DEPS_append = " 
> ${@bb.utils.contains('DISTRO_FEATURES','systemd','
>  PACKAGES =+ "${PN}-functions ${PN}-sushell"
>  RDEPENDS_${PN} = "initd-functions \
>
> ${@bb.utils.contains('DISTRO_FEATURES','selinux','${PN}-sushell','',d)} \
> +  init-system-helpers-service \
>"
>  # Recommend pn-functions so that it will be a preferred default provider for 
> initd-functions
>  RRECOMMENDS_${PN} = "${PN}-functions"
> -- 
> 2.17.1
> 

> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all me

Re: [OE-core] [meta-oe,zeus][PATCH] tremor: update SRC_URI as project moved to gitlab

[Rahul Kumar]

Hi Denys,

I apologize, By Mistake it happened.
Now i have sent it to the correct mailing list .

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rah...@mvista.com



On Thu, Jun 4, 2020 at 11:39 PM Denys Dmytriyenko  wrote:

> Why openembedded-core mailing list?
>
> On Thu, Jun 04, 2020 at 11:17:08PM +0530, Rahul Kumar wrote:
> > From: Armin Kuster 
> >
> > It appears Xiph.Org is now on gitlab
> > https://gitlab.xiph.org/xiph
> >
> > Signed-off-by: Armin Kuster 
> > Signed-off-by: Khem Raj 
> > (cherry picked from commit cc6e59fdff71e47ef5b9b40aab3bcd9438960ea4)
> > Signed-off-by: Rahul Kumar 
> > ---
> >  meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta-multimedia/recipes-multimedia/tremor/
> tremor_20180319.bb b/meta-multimedia/recipes-multimedia/tremor/
> tremor_20180319.bb
> > index beeb23a..d2ad961 100644
> > --- a/meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb
> > +++ b/meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb
> > @@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=db1b7a668b2a6f47b2af88fb008ad555 \
> >
> file://os.h;beginline=3;endline=14;md5=5c0af5e1bedef3ce8178c89f48cd6f1f"
> >  DEPENDS = "libogg"
> >
> > -SRC_URI = "git://git.xiph.org/tremor.git;protocol=https \
> > +SRC_URI = "git://gitlab.xiph.org/xiph/tremor.git;protocol=https \
> > file://obsolete_automake_macros.patch;striplevel=0 \
> > file://tremor-arm-thumb2.patch \
> >  "
> > --
> > 2.7.4
> >
>
> > 
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139229): 
https://lists.openembedded.org/g/openembedded-core/message/139229
Mute This Topic: https://lists.openembedded.org/mt/74676752/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [meta-oe,zeus][PATCH] tremor: update SRC_URI as project moved to gitlab

[Denys Dmytriyenko]

Why openembedded-core mailing list?

On Thu, Jun 04, 2020 at 11:17:08PM +0530, Rahul Kumar wrote:
> From: Armin Kuster 
> 
> It appears Xiph.Org is now on gitlab
> https://gitlab.xiph.org/xiph
> 
> Signed-off-by: Armin Kuster 
> Signed-off-by: Khem Raj 
> (cherry picked from commit cc6e59fdff71e47ef5b9b40aab3bcd9438960ea4)
> Signed-off-by: Rahul Kumar 
> ---
>  meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb 
> b/meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb
> index beeb23a..d2ad961 100644
> --- a/meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb
> +++ b/meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb
> @@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=db1b7a668b2a6f47b2af88fb008ad555 \
>  
> file://os.h;beginline=3;endline=14;md5=5c0af5e1bedef3ce8178c89f48cd6f1f"
>  DEPENDS = "libogg"
>  
> -SRC_URI = "git://git.xiph.org/tremor.git;protocol=https \
> +SRC_URI = "git://gitlab.xiph.org/xiph/tremor.git;protocol=https \
> file://obsolete_automake_macros.patch;striplevel=0 \
> file://tremor-arm-thumb2.patch \
>  "
> -- 
> 2.7.4
> 

> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139228): 
https://lists.openembedded.org/g/openembedded-core/message/139228
Mute This Topic: https://lists.openembedded.org/mt/74676752/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for tremor: update SRC_URI as project moved to gitlab

[Patchwork]

== Series Details ==

Series: tremor: update SRC_URI as project moved to gitlab
Revision: 1
URL   : https://patchwork.openembedded.org/series/24487/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[meta-oe,zeus] tremor: update SRC_URI as project moved to 
gitlab
 Issue Series sent to the wrong mailing list 
[test_target_mailing_list] 
  Suggested fixCheck the project's README (meta-oe,zeus) and send the patch 
to the indicated list

* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  zeus (currently at ee95a39928)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139227): 
https://lists.openembedded.org/g/openembedded-core/message/139227
Mute This Topic: https://lists.openembedded.org/mt/74677089/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [meta-oe,zeus][PATCH] tremor: update SRC_URI as project moved to gitlab

[Rahul Kumar]

From: Armin Kuster 

It appears Xiph.Org is now on gitlab
https://gitlab.xiph.org/xiph

Signed-off-by: Armin Kuster 
Signed-off-by: Khem Raj 
(cherry picked from commit cc6e59fdff71e47ef5b9b40aab3bcd9438960ea4)
Signed-off-by: Rahul Kumar 
---
 meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb 
b/meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb
index beeb23a..d2ad961 100644
--- a/meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb
+++ b/meta-multimedia/recipes-multimedia/tremor/tremor_20180319.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=db1b7a668b2a6f47b2af88fb008ad555 \
 
file://os.h;beginline=3;endline=14;md5=5c0af5e1bedef3ce8178c89f48cd6f1f"
 DEPENDS = "libogg"
 
-SRC_URI = "git://git.xiph.org/tremor.git;protocol=https \
+SRC_URI = "git://gitlab.xiph.org/xiph/tremor.git;protocol=https \
file://obsolete_automake_macros.patch;striplevel=0 \
file://tremor-arm-thumb2.patch \
 "
-- 
2.7.4

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139226): 
https://lists.openembedded.org/g/openembedded-core/message/139226
Mute This Topic: https://lists.openembedded.org/mt/74676752/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 2/2] archiver: Capture git submodules in mirror archiver

[Paul Barker]

Using the new Fetch.expanded_urldata() function we can get URL data for
all git submodules.

Signed-off-by: Paul Barker 
---
 meta/classes/archiver.bbclass| 13 +++---
 meta/lib/oeqa/selftest/cases/archiver.py | 54 
 2 files changed, 60 insertions(+), 7 deletions(-)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index 780c562b68..c2c049c343 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -345,13 +345,12 @@ python do_ar_mirror() {
 
 fetcher = bb.fetch2.Fetch(src_uri, d)
 
-for url in fetcher.urls:
-if is_excluded(url):
-bb.note('Skipping excluded url: %s' % (url))
+for ud in fetcher.expanded_urldata():
+if is_excluded(ud.url):
+bb.note('Skipping excluded url: %s' % (ud.url))
 continue
 
-bb.note('Archiving url: %s' % (url))
-ud = fetcher.ud[url]
+bb.note('Archiving url: %s' % (ud.url))
 ud.setup_localpath(d)
 localpath = None
 
@@ -367,7 +366,7 @@ python do_ar_mirror() {
 if len(ud.mirrortarballs) and not localpath:
 bb.warn('Mirror tarballs are listed for a source but none are 
present. ' \
 'Falling back to original download.\n' \
-'SRC_URI = %s' % (url))
+'SRC_URI = %s' % (ud.url))
 
 # Check original download
 if not localpath:
@@ -376,7 +375,7 @@ python do_ar_mirror() {
 
 if not localpath or not os.path.exists(localpath):
 bb.fatal('Original download is missing for a source.\n' \
-'SRC_URI = %s' % (url))
+'SRC_URI = %s' % (ud.url))
 
 # We now have an appropriate localpath
 bb.note('Copying source mirror')
diff --git a/meta/lib/oeqa/selftest/cases/archiver.py 
b/meta/lib/oeqa/selftest/cases/archiver.py
index bc5447d2a3..37efed57c8 100644
--- a/meta/lib/oeqa/selftest/cases/archiver.py
+++ b/meta/lib/oeqa/selftest/cases/archiver.py
@@ -255,3 +255,57 @@ class Archiver(OESelftestTestCase):
 glob_str = os.path.join(bb_vars['DEPLOY_DIR_SRC'], 'mirror', 
target_file_name)
 glob_result = glob.glob(glob_str)
 self.assertTrue(glob_result, 'Missing archive file %s' % 
(target_file_name))
+
+def test_archiver_mode_mirror_gitsm(self):
+"""
+Test that the archiver correctly handles git submodules with
+`ARCHIVER_MODE[src] = "mirror"`.
+"""
+features = 'INHERIT += "archiver"\n'
+features += 'ARCHIVER_MODE[src] = "mirror"\n'
+features += 'ARCHIVER_MODE[mirror] = "combined"\n'
+features += 'BB_GENERATE_MIRROR_TARBALLS = "1"\n'
+features += 'COPYLEFT_LICENSE_INCLUDE = "*"\n'
+self.write_config(features)
+
+bitbake('-c clean git-submodule-test')
+bitbake('-c deploy_archives -f git-submodule-test')
+
+bb_vars = get_bb_vars(['DEPLOY_DIR_SRC'])
+for target_file_name in [
+'git2_git.yoctoproject.org.git-submodule-test.tar.gz',
+'git2_git.yoctoproject.org.bitbake-gitsm-test1.tar.gz',
+'git2_git.yoctoproject.org.bitbake-gitsm-test2.tar.gz',
+'git2_git.openembedded.org.bitbake.tar.gz'
+]:
+target_path = os.path.join(bb_vars['DEPLOY_DIR_SRC'], 'mirror', 
target_file_name)
+self.assertTrue(os.path.exists(target_path))
+
+def test_archiver_mode_mirror_gitsm_shallow(self):
+"""
+Test that the archiver correctly handles git submodules with
+`ARCHIVER_MODE[src] = "mirror"`.
+"""
+features = 'INHERIT += "archiver"\n'
+features += 'ARCHIVER_MODE[src] = "mirror"\n'
+features += 'ARCHIVER_MODE[mirror] = "combined"\n'
+features += 'BB_GENERATE_MIRROR_TARBALLS = "1"\n'
+features += 'COPYLEFT_LICENSE_INCLUDE = "*"\n'
+features += 'BB_GIT_SHALLOW = "1"\n'
+features += 'BB_GENERATE_SHALLOW_TARBALLS = "1"\n'
+features += 'DL_DIR = "${TOPDIR}/downloads-shallow"\n'
+self.write_config(features)
+
+bitbake('-c clean git-submodule-test')
+bitbake('-c deploy_archives -f git-submodule-test')
+
+bb_vars = get_bb_vars(['DEPLOY_DIR_SRC'])
+for target_file_name in [
+
'gitsmshallow_git.yoctoproject.org.git-submodule-test_a2885dd-1_master.tar.gz',
+
'gitsmshallow_git.yoctoproject.org.bitbake-gitsm-test1_bare_120f4c7-1.tar.gz',
+
'gitsmshallow_git.yoctoproject.org.bitbake-gitsm-test2_bare_f66699e-1.tar.gz',
+'gitsmshallow_git.openembedded.org.bitbake_bare_52a144a-1.tar.gz',
+'gitsmshallow_git.openembedded.org.bitbake_bare_c39b997-1.tar.gz'
+]:
+target_path = os.path.join(bb_vars['DEPLOY_DIR_SRC'], 'mirror', 
target_file_name)
+self.assertTrue(os.path.exists(target_path))
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive

[OE-core] [PATCH v2 0/2] Capture git submodules in mirror archiver

[Paul Barker]

Changes in v2:

  * Use the git-submodule-test repo on git.yoctoproject.com instead of
ovmf so that the test doesn't take forever.

  * Fix test_archiver_mode_mirror_gitsm_shallow. As the
git-submodule-test recipe isn't likely to change we can be explicit
with file names instead of using globs.

Paul Barker (2):
  selftest: git-submodule-test: New recipe for testing a gitsm SRC_URI
  archiver: Capture git submodules in mirror archiver

 .../git-submodule-test/git-submodule-test.bb  |  8 +++
 meta/classes/archiver.bbclass | 13 +++--
 meta/lib/oeqa/selftest/cases/archiver.py  | 54 +++
 3 files changed, 68 insertions(+), 7 deletions(-)
 create mode 100644 
meta-selftest/recipes-test/git-submodule-test/git-submodule-test.bb

-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139223): 
https://lists.openembedded.org/g/openembedded-core/message/139223
Mute This Topic: https://lists.openembedded.org/mt/74676445/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 1/2] selftest: git-submodule-test: New recipe for testing a gitsm SRC_URI

[Paul Barker]

Signed-off-by: Paul Barker 
---
 .../recipes-test/git-submodule-test/git-submodule-test.bb | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 
meta-selftest/recipes-test/git-submodule-test/git-submodule-test.bb

diff --git 
a/meta-selftest/recipes-test/git-submodule-test/git-submodule-test.bb 
b/meta-selftest/recipes-test/git-submodule-test/git-submodule-test.bb
new file mode 100644
index 00..08089b4186
--- /dev/null
+++ b/meta-selftest/recipes-test/git-submodule-test/git-submodule-test.bb
@@ -0,0 +1,8 @@
+SUMMARY = "Test recipe for fetching git submodules"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+INHIBIT_DEFAULT_DEPS = "1"
+
+SRC_URI = "gitsm://git.yoctoproject.org/git-submodule-test"
+SRCREV = "a2885dd7d25380d23627e7544b7bbb55014b16ee"
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139224): 
https://lists.openembedded.org/g/openembedded-core/message/139224
Mute This Topic: https://lists.openembedded.org/mt/74676446/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH V2] libunwind: Fix build on aarch64/musl

[Khem Raj]

Backport a patch from upstream

Signed-off-by: Khem Raj 
---
v2: This patch is already upstream, so apply a backport instead

 .../libunwind/libunwind/sigset_t.patch| 28 +++
 .../libunwind/libunwind_1.4.0.bb  |  1 +
 2 files changed, 29 insertions(+)
 create mode 100644 meta/recipes-support/libunwind/libunwind/sigset_t.patch

diff --git a/meta/recipes-support/libunwind/libunwind/sigset_t.patch 
b/meta/recipes-support/libunwind/libunwind/sigset_t.patch
new file mode 100644
index 00..6baaa77db5
--- /dev/null
+++ b/meta/recipes-support/libunwind/libunwind/sigset_t.patch
@@ -0,0 +1,28 @@
+From 5df1555828add4e256cb4bba49fc22127c34 Mon Sep 17 00:00:00 2001
+From: Dave Watson 
+Date: Wed, 27 May 2020 08:21:04 -0700
+Subject: [PATCH] aarch64: Fix __sigset build issue on muslC
+
+Described in issue #176.   Taken from Alpine Linux project.
+
+Change __sigset_t to sigset_t
+
+Upstream-Status: Backport 
[https://github.com/libunwind/libunwind/commit/5df1555828]
+Signed-off-by: Khem Raj 
+---
+ include/libunwind-aarch64.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/include/libunwind-aarch64.h b/include/libunwind-aarch64.h
+index db01a9f69..d1bd8708f 100644
+--- a/include/libunwind-aarch64.h
 b/include/libunwind-aarch64.h
+@@ -202,7 +202,7 @@ typedef struct
+   unsigned long uc_flags;
+   struct ucontext *uc_link;
+   stack_t uc_stack;
+-  __sigset_t uc_sigmask;
++  sigset_t uc_sigmask;
+   struct unw_sigcontext uc_mcontext;
+   } unw_tdep_context_t;
+ 
diff --git a/meta/recipes-support/libunwind/libunwind_1.4.0.bb 
b/meta/recipes-support/libunwind/libunwind_1.4.0.bb
index f50205f1b9..34c2249e91 100644
--- a/meta/recipes-support/libunwind/libunwind_1.4.0.bb
+++ b/meta/recipes-support/libunwind/libunwind_1.4.0.bb
@@ -7,6 +7,7 @@ SRC_URI = 
"http://download.savannah.nongnu.org/releases/libunwind/libunwind-${PV
file://0004-Fix-build-on-mips-musl.patch \

file://0005-ppc32-Consider-ucontext-mismatches-between-glibc-and.patch \
file://0006-Fix-for-X32.patch \
+   file://sigset_t.patch \
"
 SRC_URI_append_libc-musl = " file://musl-header-conflict.patch"
 
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139222): 
https://lists.openembedded.org/g/openembedded-core/message/139222
Mute This Topic: https://lists.openembedded.org/mt/74675069/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] libunwind: Fix build on aarch64/musl

[Khem Raj]

Although this patch should be applied irrespective of libc but
kept it musl specific to avoid extra testing.

Signed-off-by: Khem Raj 
---
 .../libunwind/libunwind/sigset_t.patch| 29 +++
 .../libunwind/libunwind_1.4.0.bb  |  5 +++-
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-support/libunwind/libunwind/sigset_t.patch

diff --git a/meta/recipes-support/libunwind/libunwind/sigset_t.patch 
b/meta/recipes-support/libunwind/libunwind/sigset_t.patch
new file mode 100644
index 00..4fb7744cdf
--- /dev/null
+++ b/meta/recipes-support/libunwind/libunwind/sigset_t.patch
@@ -0,0 +1,29 @@
+Do no use __sigset_t which is in private libc namespace
+replace it with sigset_t, This also makes it portable
+to musl.
+
+Fixes
+
+../../libunwind-1.4.0/include/libunwind-aarch64.h:195:2: error: unknown type 
name '__sigset_t'
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+--- a/include/libunwind-aarch64.h
 b/include/libunwind-aarch64.h
+@@ -34,6 +34,7 @@ extern "C" {
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #define UNW_TARGET  aarch64
+ #define UNW_TARGET_AARCH64  1
+@@ -192,7 +193,7 @@ typedef struct
+   unsigned long uc_flags;
+   struct ucontext *uc_link;
+   stack_t uc_stack;
+-  __sigset_t uc_sigmask;
++  sigset_t uc_sigmask;
+   struct unw_sigcontext uc_mcontext;
+   } unw_tdep_context_t;
+ 
diff --git a/meta/recipes-support/libunwind/libunwind_1.4.0.bb 
b/meta/recipes-support/libunwind/libunwind_1.4.0.bb
index f50205f1b9..f9036326d5 100644
--- a/meta/recipes-support/libunwind/libunwind_1.4.0.bb
+++ b/meta/recipes-support/libunwind/libunwind_1.4.0.bb
@@ -8,7 +8,10 @@ SRC_URI = 
"http://download.savannah.nongnu.org/releases/libunwind/libunwind-${PV

file://0005-ppc32-Consider-ucontext-mismatches-between-glibc-and.patch \
file://0006-Fix-for-X32.patch \
"
-SRC_URI_append_libc-musl = " file://musl-header-conflict.patch"
+SRC_URI_append_libc-musl = "\
+   file://musl-header-conflict.patch \
+   file://sigset_t.patch \   
+   "
 
 SRC_URI[md5sum] = "5114504c74ac3992ac06aa551cd55678"
 SRC_URI[sha256sum] = 
"df59c931bd4d7ebfd83ee481c943edf015138089b8e50abed8d9c57ba9338435"
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139221): 
https://lists.openembedded.org/g/openembedded-core/message/139221
Mute This Topic: https://lists.openembedded.org/mt/74674699/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][warrior] pseudo: Fix enum typedef

[Ernst Sj?strand]

Ubuntu 20.04 doesn't have gcc 10 as default, it's still 9. So I guess that's 
different from Fedora 32
that someone mentioned.

Regards
//Ernst

Thu 2020-06-04 klockan 15:06 +0100 skrev Richard Purdie:

On Thu, 2020-06-04 at 15:57 +0200, Quentin Schulz wrote:

On Thu, Jun 04, 2020 at 03:49:28PM +0200, Andreas Müller wrote:

On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie

<



richard.pur...@linuxfoundation.org

> wrote:

On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:

On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie

<



richard.pur...@linuxfoundation.org

> wrote:

On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:

From: Jacob Kroon <



jacob.kr...@gmail.com

>


'pseudo_access_t' is a type, so use typedef.


Fixes building pseudo with gcc 10 where -fno-common is the

default.


(Backport of OE-Core rev:

a7d519f742aadc9110c2401f359254210a784f6b)


Signed-off-by: Jacob Kroon <



jacob.kr...@gmail.com

>

Signed-off-by: Richard Purdie <



richard.pur...@linuxfoundation.org


Signed-off-by: Andreas Müller <



schnitzelt...@gmail.com

>


Does warrior otherwise work on gcc10 hosts?

Not yet but I am working on it.


I think to make a decision on whether we plan to support gcc10 or not

we'll need to know the scope of the changes. I'm starting to worry this

would be a bit too invasive, particularly as warrior is about to enter

community support or EOL depending on whether there is a maintainer.


I see. Problems for me - job's hat on - are:


1. we're close to release a product based on warrior (and a new

colleague of mine has just installed Fedora 32 with gcc 10 - that's

why I ask for it)

2. my tests with dunfell were - hmm - not running out of the box exactly.


So we should decide to upgrade to dunfell. That is what I use for

private raspi-images an am very close to happy.



Dang, I was silently but closely following the discussion hoping to be

able to apply more or less the same patches on top of thud. Same issue

as yours, colleagues moving to Ubuntu 20.04 with gcc 10+. I guess it's

docker time :/ (there'll always be that one client that will not want to

upgrade to newer releases).


Or maybe we can support gcc10 on the community branch once it's EOL (or

doing the job ourselves..). What seems to be the big worry about

supporting gcc10 on warrior/thud? Just so I can explain why we should go

the docker route instead of spending time on making thud (and we still

have krogoth for some...) build with gcc10 and maybe start working on

upgrading those we can to newer releases. Basically what are the

expected big hurdles on the way?


Your other option would be buildtools tarball for the f32/ubuntu2004

systems.


I could see a case for backporting the buildtools tarball

installer/wrapper for those older releases as a way of fixing these

issues.


Cheers,


Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139220): 
https://lists.openembedded.org/g/openembedded-core/message/139220
Mute This Topic: https://lists.openembedded.org/mt/74669421/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][warrior] pseudo: Fix enum typedef

[Martin Jansa]

Maybe I'm reading RP's reply differently, but I think he just asked to
collect all necessary changes for warrior to support newer host, before
they are accepted.

It doesn't help much when only one smaller issue is fixed and the rest
still needs to be figured out locally and the commit message might even
mislead people in assuming that gcc-10 on host is now supported in
warrior/thud.

FWIW: I've built some smaller thud based images on 20.04 with only small
modifications, e.g. fix for qemu:
https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/thud&id=68475d0255c4089538886d1ee2cab6b6efd62ce1
there aren't probably many issues left, so it just needs someone to test it
more properly and collect all needed fixes to apply them at the same time
or give up if it shows too many difficult to solve issues (I doubt that).

In worst case they might be rejected, but then it would be still useful to
have them in one pull request and share them with other interested parties.

Cheers,

On Thu, Jun 4, 2020 at 3:58 PM Quentin Schulz <
quentin.sch...@streamunlimited.com> wrote:

> On Thu, Jun 04, 2020 at 03:49:28PM +0200, Andreas Müller wrote:
> > On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie
> >  wrote:
> > >
> > > On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> > > > On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
> > > >  wrote:
> > > > > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > > > > From: Jacob Kroon 
> > > > > >
> > > > > > 'pseudo_access_t' is a type, so use typedef.
> > > > > >
> > > > > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > > > > default.
> > > > > >
> > > > > > (Backport of OE-Core rev:
> > > > > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > > > >
> > > > > > Signed-off-by: Jacob Kroon 
> > > > > > Signed-off-by: Richard Purdie <
> richard.pur...@linuxfoundation.org
> > > > > > >
> > > > > > Signed-off-by: Andreas Müller 
> > > > >
> > > > > Does warrior otherwise work on gcc10 hosts?
> > > > Not yet but I am working on it.
> > >
> > > I think to make a decision on whether we plan to support gcc10 or not
> > > we'll need to know the scope of the changes. I'm starting to worry this
> > > would be a bit too invasive, particularly as warrior is about to enter
> > > community support or EOL depending on whether there is a maintainer.
> > >
> > I see. Problems for me - job's hat on - are:
> >
> > 1. we're close to release a product based on warrior (and a new
> > colleague of mine has just installed Fedora 32 with gcc 10 - that's
> > why I ask for it)
> > 2. my tests with dunfell were - hmm - not running out of the box exactly.
> >
> > So we should decide to upgrade to dunfell. That is what I use for
> > private raspi-images an am very close to happy.
> >
>
> Dang, I was silently but closely following the discussion hoping to be
> able to apply more or less the same patches on top of thud. Same issue
> as yours, colleagues moving to Ubuntu 20.04 with gcc 10+. I guess it's
> docker time :/ (there'll always be that one client that will not want to
> upgrade to newer releases).
>
> Or maybe we can support gcc10 on the community branch once it's EOL (or
> doing the job ourselves..). What seems to be the big worry about
> supporting gcc10 on warrior/thud? Just so I can explain why we should go
> the docker route instead of spending time on making thud (and we still
> have krogoth for some...) build with gcc10 and maybe start working on
> upgrading those we can to newer releases. Basically what are the
> expected big hurdles on the way?
>
> Cheers,
> Quentin
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139219): 
https://lists.openembedded.org/g/openembedded-core/message/139219
Mute This Topic: https://lists.openembedded.org/mt/74669421/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][warrior] pseudo: Fix enum typedef

[Richard Purdie]

On Thu, 2020-06-04 at 15:57 +0200, Quentin Schulz wrote:
> On Thu, Jun 04, 2020 at 03:49:28PM +0200, Andreas Müller wrote:
> > On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie
> >  wrote:
> > > On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> > > > On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
> > > >  wrote:
> > > > > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > > > > From: Jacob Kroon 
> > > > > > 
> > > > > > 'pseudo_access_t' is a type, so use typedef.
> > > > > > 
> > > > > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > > > > default.
> > > > > > 
> > > > > > (Backport of OE-Core rev:
> > > > > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > > > > 
> > > > > > Signed-off-by: Jacob Kroon 
> > > > > > Signed-off-by: Richard Purdie  > > > > > Signed-off-by: Andreas Müller 
> > > > > 
> > > > > Does warrior otherwise work on gcc10 hosts?
> > > > Not yet but I am working on it.
> > > 
> > > I think to make a decision on whether we plan to support gcc10 or not
> > > we'll need to know the scope of the changes. I'm starting to worry this
> > > would be a bit too invasive, particularly as warrior is about to enter
> > > community support or EOL depending on whether there is a maintainer.
> > > 
> > I see. Problems for me - job's hat on - are:
> > 
> > 1. we're close to release a product based on warrior (and a new
> > colleague of mine has just installed Fedora 32 with gcc 10 - that's
> > why I ask for it)
> > 2. my tests with dunfell were - hmm - not running out of the box exactly.
> > 
> > So we should decide to upgrade to dunfell. That is what I use for
> > private raspi-images an am very close to happy.
> > 
> 
> Dang, I was silently but closely following the discussion hoping to be
> able to apply more or less the same patches on top of thud. Same issue
> as yours, colleagues moving to Ubuntu 20.04 with gcc 10+. I guess it's
> docker time :/ (there'll always be that one client that will not want to
> upgrade to newer releases).
> 
> Or maybe we can support gcc10 on the community branch once it's EOL (or
> doing the job ourselves..). What seems to be the big worry about
> supporting gcc10 on warrior/thud? Just so I can explain why we should go
> the docker route instead of spending time on making thud (and we still
> have krogoth for some...) build with gcc10 and maybe start working on
> upgrading those we can to newer releases. Basically what are the
> expected big hurdles on the way?

Your other option would be buildtools tarball for the f32/ubuntu2004
systems.

I could see a case for backporting the buildtools tarball
installer/wrapper for those older releases as a way of fixing these
issues.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139218): 
https://lists.openembedded.org/g/openembedded-core/message/139218
Mute This Topic: https://lists.openembedded.org/mt/74669421/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][warrior] pseudo: Fix enum typedef

[Quentin Schulz]

On Thu, Jun 04, 2020 at 03:49:28PM +0200, Andreas Müller wrote:
> On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie
>  wrote:
> >
> > On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> > > On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
> > >  wrote:
> > > > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > > > From: Jacob Kroon 
> > > > >
> > > > > 'pseudo_access_t' is a type, so use typedef.
> > > > >
> > > > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > > > default.
> > > > >
> > > > > (Backport of OE-Core rev:
> > > > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > > >
> > > > > Signed-off-by: Jacob Kroon 
> > > > > Signed-off-by: Richard Purdie  > > > > >
> > > > > Signed-off-by: Andreas Müller 
> > > >
> > > > Does warrior otherwise work on gcc10 hosts?
> > > Not yet but I am working on it.
> >
> > I think to make a decision on whether we plan to support gcc10 or not
> > we'll need to know the scope of the changes. I'm starting to worry this
> > would be a bit too invasive, particularly as warrior is about to enter
> > community support or EOL depending on whether there is a maintainer.
> >
> I see. Problems for me - job's hat on - are:
> 
> 1. we're close to release a product based on warrior (and a new
> colleague of mine has just installed Fedora 32 with gcc 10 - that's
> why I ask for it)
> 2. my tests with dunfell were - hmm - not running out of the box exactly.
> 
> So we should decide to upgrade to dunfell. That is what I use for
> private raspi-images an am very close to happy.
> 

Dang, I was silently but closely following the discussion hoping to be
able to apply more or less the same patches on top of thud. Same issue
as yours, colleagues moving to Ubuntu 20.04 with gcc 10+. I guess it's
docker time :/ (there'll always be that one client that will not want to
upgrade to newer releases).

Or maybe we can support gcc10 on the community branch once it's EOL (or
doing the job ourselves..). What seems to be the big worry about
supporting gcc10 on warrior/thud? Just so I can explain why we should go
the docker route instead of spending time on making thud (and we still
have krogoth for some...) build with gcc10 and maybe start working on
upgrading those we can to newer releases. Basically what are the
expected big hurdles on the way?

Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139217): 
https://lists.openembedded.org/g/openembedded-core/message/139217
Mute This Topic: https://lists.openembedded.org/mt/74669421/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][warrior] pseudo: Fix enum typedef

[Andreas Müller]

On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie
 wrote:
>
> On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> > On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
> >  wrote:
> > > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > > From: Jacob Kroon 
> > > >
> > > > 'pseudo_access_t' is a type, so use typedef.
> > > >
> > > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > > default.
> > > >
> > > > (Backport of OE-Core rev:
> > > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > >
> > > > Signed-off-by: Jacob Kroon 
> > > > Signed-off-by: Richard Purdie  > > > >
> > > > Signed-off-by: Andreas Müller 
> > >
> > > Does warrior otherwise work on gcc10 hosts?
> > Not yet but I am working on it.
>
> I think to make a decision on whether we plan to support gcc10 or not
> we'll need to know the scope of the changes. I'm starting to worry this
> would be a bit too invasive, particularly as warrior is about to enter
> community support or EOL depending on whether there is a maintainer.
>
I see. Problems for me - job's hat on - are:

1. we're close to release a product based on warrior (and a new
colleague of mine has just installed Fedora 32 with gcc 10 - that's
why I ask for it)
2. my tests with dunfell were - hmm - not running out of the box exactly.

So we should decide to upgrade to dunfell. That is what I use for
private raspi-images an am very close to happy.

Thanks for 'warning' me

Andreas
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139216): 
https://lists.openembedded.org/g/openembedded-core/message/139216
Mute This Topic: https://lists.openembedded.org/mt/74669421/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] The change pointed to by a .scc file not detected when compile kernel

[Bruce Ashfield]

On Thu, Jun 4, 2020 at 12:52 AM Yu, Mingli  wrote:
>
> Hi Bruce,
>
> Currently, the change pointed to by a .scc file not detected when
> compile kernel, for example:
>
> 1, add DISTRO_FEATURES_append = " virtualization" to conf/local.conf to
> enable virtualization DISTRO_FEATURES and also add meta-virtualization
> layer to conf/bblayers.conf
>
> 2, bitbake -cconfigure linux-yocto
>
> 3,
> $ grep -Rn CONFIG_IO_DELAY_0XED
> tmp/work/qemux86_64-wrs-linux/linux-yocto/5.4.43+gitAUTOINC+aafb8f095e_9e1b13d7f9-r0/linux-qemux86_64-standard-build/.config
> 5367:# CONFIG_IO_DELAY_0XED is not set
>
> 4, modify the lxc.cfg which introduced by lxc.scc under
> meta-virtualization layer
> $ git diff
> diff --git a/recipes-kernel/linux/linux-yocto/lxc.cfg
> b/recipes-kernel/linux/linux-yocto/lxc.cfg
> index 3fefc03..b7a19a8 100644
> --- a/recipes-kernel/linux/linux-yocto/lxc.cfg
> +++ b/recipes-kernel/linux/linux-yocto/lxc.cfg
> @@ -1,3 +1,4 @@
> +CONFIG_IO_DELAY_0XED=y
>   CONFIG_CGROUP_DEVICE=y
>   CONFIG_CPUSETS=y
>   CONFIG_PROC_PID_CPUSET=y
>
>
> 5, bitbake -cconfigure linux-yocto
>
> 6,
> $ grep -Rn CONFIG_IO_DELAY_0XED
> tmp-glibc/work/qemux86_64-wrs-linux/linux-yocto/5.4.43+gitAUTOINC+aafb8f095e_9e1b13d7f9-r0/linux-qemux86_64-standard-build/.config
> 5367:# CONFIG_IO_DELAY_0XED is not set
>
> The change for CONFIG_IO_DELAY_0XED doesn't take effect.

Does the same thing happen with a cleanall ? There's an open bug about
the checksuming of those SRC_URI elements, and you are likely hitting
it if there's no cleansstate or cleanall happening.

Also, you've confirmed that CONFIG_IO_DELAY_0XED isn't missing any
config options that it has as dependencies ?

Bruce

>
> Thanks,
> Mingli



-- 
- 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 (#139215): 
https://lists.openembedded.org/g/openembedded-core/message/139215
Mute This Topic: https://lists.openembedded.org/mt/74665912/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][warrior] pseudo: Fix enum typedef

[Richard Purdie]

On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
>  wrote:
> > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > From: Jacob Kroon 
> > > 
> > > 'pseudo_access_t' is a type, so use typedef.
> > > 
> > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > default.
> > > 
> > > (Backport of OE-Core rev:
> > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > 
> > > Signed-off-by: Jacob Kroon 
> > > Signed-off-by: Richard Purdie  > > >
> > > Signed-off-by: Andreas Müller 
> > 
> > Does warrior otherwise work on gcc10 hosts?
> Not yet but I am working on it.

I think to make a decision on whether we plan to support gcc10 or not
we'll need to know the scope of the changes. I'm starting to worry this
would be a bit too invasive, particularly as warrior is about to enter
community support or EOL depending on whether there is a maintainer.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139214): 
https://lists.openembedded.org/g/openembedded-core/message/139214
Mute This Topic: https://lists.openembedded.org/mt/74669421/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v3] glibc: move ld.so.conf back to main package

[Richard Purdie]

On Wed, 2020-06-03 at 13:44 -0700, Andre McCurdy wrote:
> On Wed, Jun 3, 2020 at 12:38 AM Rasmus Villemoes
>  wrote:
> > On 02/06/2020 23.46, Andre McCurdy wrote:
> > > On Tue, Jun 2, 2020 at 2:15 PM Phil Blundell via
> > > lists.openembedded.org 
> > > wrote:
> > > > On Tue, Jun 02, 2020 at 09:17:44PM +0100, Richard Purdie wrote:
> > > > > I understand the concern, I am a little torn on this as
> > > > > adding in too
> > > > > many different controls and options complicates the test
> > > > > matrix and
> > > > > makes things harder for users.
> > > > > 
> > > > > You're effectively suggesting a new DISTRO_FEATURE to control
> > > > > this? or
> > > > > maybe better, perhaps a glibc PACKAGECONFIG?
> > > > 
> > > > Yes, right.  I don't think it need be a DISTRO_FEATURE because
> > > > nothing
> > > > outside glibc needs to care.
> > > > 
> > > > Here are the scenarios that I think matter, ordered from
> > > > simplest to
> > > > most complex:
> > > > 
> > > > 1. Immutable filesystem, every library installed in the place
> > > > where
> > > > ld.so would first look for it anyway (i.e. everything in
> > > > {/usr}/lib).
> > > > In this case, we don't want ldconfig (because it can never do
> > > > anything
> > > > useful), we don't want ld.so.cache and we don't want ld.so.conf
> > > > because they would cause ld.so to do extra file loads and
> > > > computation
> > > > but end up with the same result that it would anyway.
> > > > 
> > > > 2. Immutable filesystem but some libraries are in places that
> > > > ld.so
> > > > wouldn't automatically know about.  In this case we do want
> > > > ld.so.conf
> > > > and ld.so.cache, but we still don't want ldconfig.
> > > > 
> > > > 3. Mutable filesystem where arbitrary binaries can be installed
> > > > in
> > > > arbitrary places.  It's probably debatable whether ldconfig is
> > > > needed
> > > > in all these cases, but clearly it's needed in some and I think
> > > > at
> > > > this point it can be left to a DISTRO decision how exactly they
> > > > want
> > > > to optimize things.
> > > > 
> > > > I think right now oe-core supports #1 and #3.  The proposed
> > > > patch
> > > > seems to be aimed at #2, which is a completely valid usecase,
> > > 
> > > It seems like a weird corner case to me. Where do these libraries
> > > come
> > > from and why can't they be moved or symlinked into a standard
> > > path?
> > 
> > Pre-compiled proprietary binaries/libraries that go in
> > /opt//..., just as /opt is meant for (and no, we can't just
> > install them to /usr/lib, /usr/bin etc - partly because they
> > contain
> > hard-coded absolute paths, but also due to some not-entirely-
> > techical
> > reasons). So there's an /etc/ld.so.conf.d/.conf that needs
> > to be
> > picked up.
> > 
> > > If they are somehow special and only used by special applications
> > > then
> > > setting rpath or using LD_LIBRARY_PATH just for those
> > > applications
> > > would seem to be a better solution than enabling them globally.
> > 
> > We don't control the compilation, so rpath is out. We did consider
> > LD_LIBRARY_PATH, but figured that the ld.conf solution is more
> > robust
> > (no problems with setuid binaries or an application that
> > misguidedly
> > sanitizes the environment for subprocesses).
> 
> Unless the supplier of your binaries is completely unresponsive (if
> so, bad luck) then educating them on the usage of rpath and asking
> for
> a new release is probably the cleanest solution.
> 
> If you start your special application via a wrapper script which sets
> LD_LIBRARY_PATH then it won't be seen by anything else, so the
> concerns about other apps messing with it etc should not apply?
> 
> Relying on /etc/ld.so.conf.d/*.conf will certainly work too, but has
> two disadvantages: it will add the custom library path globally
> instead of just for the special apps and it's not portable (it's not
> supported by musl etc - although if you only care about your
> proprietary binaries pre-compiled for glibc then that won't matter to
> you).
> 
> Anyway, the original patch has been merged, so this now just a side
> discussion.

It hasn't, its still in master-next waiting for us to reach a
conclusion...

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139213): 
https://lists.openembedded.org/g/openembedded-core/message/139213
Mute This Topic: https://lists.openembedded.org/mt/74625854/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][warrior] pseudo: Fix enum typedef

[Andreas Müller]

On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
 wrote:
>
> On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > From: Jacob Kroon 
> >
> > 'pseudo_access_t' is a type, so use typedef.
> >
> > Fixes building pseudo with gcc 10 where -fno-common is the default.
> >
> > (Backport of OE-Core rev: a7d519f742aadc9110c2401f359254210a784f6b)
> >
> > Signed-off-by: Jacob Kroon 
> > Signed-off-by: Richard Purdie 
> > Signed-off-by: Andreas Müller 
>
> Does warrior otherwise work on gcc10 hosts?
Not yet but I am working on it.

Andreas
>
> Cheers,
>
> Richard
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139212): 
https://lists.openembedded.org/g/openembedded-core/message/139212
Mute This Topic: https://lists.openembedded.org/mt/74669421/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][warrior] pseudo: Fix enum typedef

[Richard Purdie]

On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> From: Jacob Kroon 
> 
> 'pseudo_access_t' is a type, so use typedef.
> 
> Fixes building pseudo with gcc 10 where -fno-common is the default.
> 
> (Backport of OE-Core rev: a7d519f742aadc9110c2401f359254210a784f6b)
> 
> Signed-off-by: Jacob Kroon 
> Signed-off-by: Richard Purdie 
> Signed-off-by: Andreas Müller 

Does warrior otherwise work on gcc10 hosts?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139211): 
https://lists.openembedded.org/g/openembedded-core/message/139211
Mute This Topic: https://lists.openembedded.org/mt/74669421/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][warrior] pseudo: Fix enum typedef

[Andreas Müller]

From: Jacob Kroon 

'pseudo_access_t' is a type, so use typedef.

Fixes building pseudo with gcc 10 where -fno-common is the default.

(Backport of OE-Core rev: a7d519f742aadc9110c2401f359254210a784f6b)

Signed-off-by: Jacob Kroon 
Signed-off-by: Richard Purdie 
Signed-off-by: Andreas Müller 
---
 .../0001-pseudo_ipc.h-Fix-enum-typedef.patch  | 31 +++
 meta/recipes-devtools/pseudo/pseudo_git.bb|  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 
meta/recipes-devtools/pseudo/files/0001-pseudo_ipc.h-Fix-enum-typedef.patch

diff --git 
a/meta/recipes-devtools/pseudo/files/0001-pseudo_ipc.h-Fix-enum-typedef.patch 
b/meta/recipes-devtools/pseudo/files/0001-pseudo_ipc.h-Fix-enum-typedef.patch
new file mode 100644
index 000..33d4ef3b2fa
--- /dev/null
+++ 
b/meta/recipes-devtools/pseudo/files/0001-pseudo_ipc.h-Fix-enum-typedef.patch
@@ -0,0 +1,31 @@
+From a491aececfedf7313d29b80d626e0964fb533548 Mon Sep 17 00:00:00 2001
+From: Jacob Kroon 
+Date: Sun, 3 May 2020 06:24:03 +0200
+Subject: [PATCH] pseudo_ipc.h: Fix enum typedef
+
+'pseudo_access_t' is a type, so use typedef.
+
+Fixes building pseudo with gcc 10 where -fno-common is the default.
+
+Signed-off-by: Jacob Kroon 
+Upstream-Status: Submitted 
[https://lists.openembedded.org/g/openembedded-core/message/137758]
+---
+ pseudo_ipc.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pseudo_ipc.h b/pseudo_ipc.h
+index caeae5c..d945257 100644
+--- a/pseudo_ipc.h
 b/pseudo_ipc.h
+@@ -29,7 +29,7 @@ typedef struct {
+   char path[];
+ } pseudo_msg_t;
+ 
+-enum {
++typedef enum {
+   PSA_EXEC = 1,
+   PSA_WRITE = (PSA_EXEC << 1),
+   PSA_READ = (PSA_WRITE << 1),
+-- 
+2.26.2
+
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 7db5bafd174..8ff003d9024 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -7,6 +7,7 @@ SRC_URI = "git://git.yoctoproject.org/pseudo \
file://moreretries.patch \
file://toomanyfiles.patch \
file://0001-Add-statx.patch \
+   file://0001-pseudo_ipc.h-Fix-enum-typedef.patch \
"
 
 SRCREV = "060058bb29f70b244e685b3c704eb0641b736f73"
-- 
2.21.3

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139210): 
https://lists.openembedded.org/g/openembedded-core/message/139210
Mute This Topic: https://lists.openembedded.org/mt/74669421/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH

[Richard Purdie]

On Fri, 2020-05-22 at 00:23 +, Mittal, Anuj wrote:
> On Thu, 2020-05-21 at 17:05 -0700, Khem Raj wrote:
> > On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj  > >
> > wrote:
> > > On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote:
> > > > On Thu, May 21, 2020 at 6:16 PM Khem Raj 
> > > > wrote:
> > > > > Now that they uses -mcpu, its better to have tune specific
> > > > > build
> > > > > directories, since aarch64 wont be appropriate any longer
> > > > 
> > > > I agree with Steve that this is a bit invasive for stable
> > > > branch,
> > > > but
> > > > on the other hand it's long overdue and if we don't improve it
> > > > in
> > > > LTS
> > > > branch then many people will need to carry local work arounds
> > > > for
> > > > multi-machine builds. +1 from me.
> > > > 
> > > 
> > > But this is against the LTS/Stable branch policy. What is the
> > > point
> > > of
> > > having a policy if we are going to keep making exceptions?
> > > There'd
> > > be
> > > other changes as well for which people might be carrying work-
> > > arounds.
> > > Would we be willing to make exceptions for all?
> > > 
> > 
> > Thanks for bringing this up. Policy exceptions are not common but
> > they
> 
> That's two exceptions in a week.
> 
> I am not against the change but I think the policy document should be
> modified to define how exceptions should/will be handled. 
> 
> > are not absent either
> > hence context is important for such changes, I am definitely
> > interested to hear
> > about how it is going to affect arm64 users at this early stage of
> > release. 
> 
> The release has been made and I think the branch is assumed to be
> stable from the time it was released and policy should be applied?
> There's no early release stage defined where-in such changes would be
> acceptable.

This series doesn't have a decision on it yet. If an exception were
made, it would be two exceptions in the lifetime of the LTS so far, not
just a week. The fact we'd like to make a point release is focusing the
fact we need to make some decisions rather than a sudden stream of
policy exceptions.

I'd also note its most likely we'd find issues just after release as
people start using things, over time it becomes much less likely. 

If such issues are identified, particularly now as people start using
it, the question is what we do about it. If we can fix things to
improve things for users and the risk is either low, or managed to a
specific subset of users who can benefit, that does seem like a
sensible thing to do.

I guess I'd hoped we could all be sensible about these things, the LTS
policy is there as a set of 'guide rails' to make decisions against but
as a maintainer, I know that not everything that makes sense neatly
fits within a written set of rules. The LTS maintainer does need to
have some ability to make decisions and I've always thought it was
clear the TSCs are the ultimate decision makers for any technical
decision the project faces should there not be consensus. 

In the case of these patches I'm not seeing anyone arguing against them
on technical grounds or saying they don't make sense other than some
things I've said to Steve! The complaint is that they break policy.

I will discuss making a escalation and final decision path clearer with
the YP TSC (who wrote/maintain the policy).

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139209): 
https://lists.openembedded.org/g/openembedded-core/message/139209
Mute This Topic: https://lists.openembedded.org/mt/74379085/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] python3-magic: add the missing rdepends

[Yu, Mingli]

From: Mingli Yu 

Add the missing rdepends to fix below error:
 # python3
 [snip]
 >>> import magic
 [snip]
 ModuleNotFoundError: No module named 'ctypes'
 ModuleNotFoundError: No module named 'tempfile'

Signed-off-by: Mingli Yu 
---
 meta/recipes-devtools/python/python3-magic_0.4.18.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3-magic_0.4.18.bb 
b/meta/recipes-devtools/python/python3-magic_0.4.18.bb
index be423adacd..101b96d31c 100644
--- a/meta/recipes-devtools/python/python3-magic_0.4.18.bb
+++ b/meta/recipes-devtools/python/python3-magic_0.4.18.bb
@@ -14,6 +14,9 @@ inherit pypi setuptools3
 SRC_URI[md5sum] = "5edc6caa39cc62641850f6b1b6f284ba"
 SRC_URI[sha256sum] = 
"b757db2a5289ea3f1ced9e60f072965243ea43a2221430048fd8cacab17be0ce"
 
-RDEPENDS_${PN} += "file"
+RDEPENDS_${PN} += "file \
+   ${PYTHON_PN}-ctypes \
+   ${PYTHON_PN}-io \
+   ${PYTHON_PN}-shell"
 
 BBCLASSEXTEND = "native"
-- 
2.24.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139208): 
https://lists.openembedded.org/g/openembedded-core/message/139208
Mute This Topic: https://lists.openembedded.org/mt/74667231/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] kmod: fix RCONFLICTS setting

[Richard Purdie]

On Tue, 2020-06-02 at 22:44 +0200, Konrad Weihmann wrote:
> Previously used libkmod2 isn't known in this scope,
> replace it with the correct libkmod
> 
> Signed-off-by: Konrad Weihmann 
> ---
>  meta/recipes-kernel/kmod/kmod_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/kmod/kmod_git.bb 
> b/meta/recipes-kernel/kmod/kmod_git.bb
> index bd21d2ff73..5cfd2238c9 100644
> --- a/meta/recipes-kernel/kmod/kmod_git.bb
> +++ b/meta/recipes-kernel/kmod/kmod_git.bb
> @@ -10,7 +10,7 @@ RCONFLICTS_${PN} += "module-init-tools-insmod-static 
> module-init-tools-depmod mo
>  RREPLACES_${PN} += "module-init-tools-insmod-static module-init-tools-depmod 
> module-init-tools"
>  
>  # to force user to remove old module-init-tools and replace them with kmod 
> variants
> -RCONFLICTS_libkmod2 += "module-init-tools-insmod-static 
> module-init-tools-depmod module-init-tools"
> +RCONFLICTS_libkmod += "module-init-tools-insmod-static 
> module-init-tools-depmod module-init-tools"

This change caused:

https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/2006

(and pretty much every other build to fail too)

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139207): 
https://lists.openembedded.org/g/openembedded-core/message/139207
Mute This Topic: https://lists.openembedded.org/mt/74636770/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-