Re: [OE-core] [PATCH 34/36] busybox: drop 0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch

2021-11-19 Thread Andre McCurdy
On Fri, Nov 19, 2021 at 12:17 AM Alexander Kanavin
 wrote:
>
> On Fri, 19 Nov 2021 at 00:14, Andre McCurdy  wrote:
>>
>> > So everything that is supposed to be there is actually present, and the 
>> > patch is indeed unneeded.
>>
>> Looks good. If you have the full strace logs for both cases then it
>> might still be useful to check which (if any) command lines are
>> changed by removing the patch, but if not then removing the whole
>> patch does seem OK.
>
> There is no tooling to compare strace files, they have process ids, and 
> probably other unrelated files that needs to be stripped out or matched.

I guess looking at the two logs in a graphical tool such as meld would
highlight if command line options completely disappear, even with the
noise of differences in process IDs etc.

> Just to reiterate: this is for the master branch, and I do insist on "if AB 
> is green then it works as intended" - if issues are found later, then the 
> right way to deal with them is to improve the AB tests, not ask maintainers 
> do even more manual work.

Yes, and I'm agreeing with you!

> Can you help me review the remaining 400 "upstream-status: pending" patches?

No. I made the decision some time ago to stop contributing to OE. Not
planning on restarting now.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#158500): 
https://lists.openembedded.org/g/openembedded-core/message/158500
Mute This Topic: https://lists.openembedded.org/mt/87122011/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 34/36] busybox: drop 0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch

2021-11-18 Thread Andre McCurdy
On Thu, Nov 18, 2021 at 2:32 AM Alexander Kanavin
 wrote:
>
> I double checked, with strace (can't trust the logs as they don't show the 
> actual linker invocation :)
>
> execve("/home/alex/development/poky/build-64-alt/tmp/work/core2-64-poky-linux/busybox/1.34.1-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc",
>  ["x86_64-poky-linux-gcc", "-m64", "-march=core2", "-mtune=core2", "-msse3", 
> "-mfpmath=sse", "-fstack-protector-strong", "-O2", "-D_FORTIFY_SOURCE=2", 
> "--sysroot=/home/alex/development/poky/build-64-alt/tmp/work/core2-64-poky-linux/busybox/1.34.1-r0/recipe-sysroot",
>  "-malign-data=abi", "-Wall", "-Wshadow", "-Wwrite-strings", "-Wundef", 
> "-Wstrict-prototypes", "-Wunused", "-Wunused-parameter", "-Wunused-function", 
> "-Wunused-value", "-Wmissing-prototypes", "-Wmissing-declarations", 
> "-Wno-format-security", "-Wdeclaration-after-statement", 
> "-Wold-style-definition", "-finline-limit=0", "-fno-builtin-strlen", 
> "-fomit-frame-pointer", "-ffunction-sections", "-fdata-sections", 
> "-fno-guess-branch-probability", "-funsigned-char", "-static-libgcc", 
> "-falign-functions=1", "-falign-jumps=1", "-falign-labels=1", 
> "-falign-loops=1", "-fno-unwind-tables", "-fno-asynchronous-unwind-tables", 
> "-fno-builtin-printf", "-Os", "-O2", "-pipe", "-g", 
> "-feliminate-unused-debug-types", "-m64", "-march=core2", "-mtune=core2", 
> "-msse3", "-mfpmath=sse", "-fstack-protector-strong", "-O2", 
> "-D_FORTIFY_SOURCE=2", "-Wl,-O1", "-Wl,--hash-style=gnu", "-Wl,--as-needed", 
> "-fmacro-prefix-map=/home/alex/development/poky/build-64-alt/tmp/work/core2-64-poky-linux/busybox/1.34.1-r0=/usr/src/debug/busybox/1.34.1-r0",
>  
> "-fdebug-prefix-map=/home/alex/development/poky/build-64-alt/tmp/work/core2-64-poky-linux/busybox/1.34.1-r0=/usr/src/debug/busybox/1.34.1-r0",
>  
> "-fdebug-prefix-map=/home/alex/development/poky/build-64-alt/tmp/work/core2-64-poky-linux/busybox/1.34.1-r0/recipe-sysroot=",
>  
> "-fdebug-prefix-map=/home/alex/development/poky/build-64-alt/tmp/work/core2-64-poky-linux/busybox/1.34.1-r0/recipe-sysroot-native=",
>  "-Wl,-z,relro,-z,now", "-o", "busybox_unstripped", "-Wl,--sort-common", 
> "-Wl,--sort-section,alignment", "-Wl,--gc-sections", "-Wl,--start-group", 
> "applets/built-in.o", "archival/lib.a", "archival/libarchive/lib.a", 
> "console-tools/lib.a", "coreutils/lib.a", "coreutils/libcoreutils/lib.a", 
> "debianutils/lib.a", "klibc-utils/lib.a", "e2fsprogs/lib.a", "editors/lib.a", 
> "findutils/lib.a", "init/lib.a", "libbb/lib.a", "libpwdgrp/lib.a", 
> "loginutils/lib.a", "mailutils/lib.a", "miscutils/lib.a", "modutils/lib.a", 
> "networking/lib.a", "networking/libiproute/lib.a", "networking/udhcp/lib.a", 
> "printutils/lib.a", "procps/lib.a", "runit/lib.a", "selinux/lib.a", 
> "shell/lib.a", "sysklogd/lib.a", "util-linux/lib.a", 
> "util-linux/volume_id/lib.a", "archival/built-in.o", 
> "archival/libarchive/built-in.o", "console-tools/built-in.o", 
> "coreutils/built-in.o", "coreutils/libcoreutils/built-in.o", 
> "debianutils/built-in.o", "klibc-utils/built-in.o", "e2fsprogs/built-in.o", 
> "editors/built-in.o", "findutils/built-in.o", "init/built-in.o", 
> "libbb/built-in.o", "libpwdgrp/built-in.o", "loginutils/built-in.o", 
> "mailutils/built-in.o", "miscutils/built-in.o", "modutils/built-in.o", 
> "networking/built-in.o", "networking/libiproute/built-in.o", 
> "networking/udhcp/built-in.o", "printutils/built-in.o", "procps/built-in.o", 
> "runit/built-in.o", "selinux/built-in.o", "shell/built-in.o", 
> "sysklogd/built-in.o", "util-linux/built-in.o", 
> "util-linux/volume_id/b

Re: [OE-core] [PATCH 34/36] busybox: drop 0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch

2021-11-17 Thread Andre McCurdy
On Wed, Nov 17, 2021 at 7:36 AM Alexander Kanavin
 wrote:
>
> This was added 10 years ago, is almost certainly non-upstreamable
> and it isn't clear what the issues it aims to fix are:
> the AB revealed no problems when the patch is removed.

The comment in the patch was: This fixes the issue where LDFLAGS
escaped with -Wl are ignored during compilation. Seems fairly clear!

Checking that the AB run didn't fail is probably not enough to justify
removing this patch. You should also confirm that LDFLAGS escaped with
-Wl (e.g. -Wl,-z,relro,-z,now when security flags are enabled, etc)
are still passed to the linker.

> Signed-off-by: Alexander Kanavin 
> ---
>  ...ing-instead-of-LD-and-use-CFLAGS-and.patch | 114 --
>  meta/recipes-core/busybox/busybox_1.34.1.bb   |   1 -
>  2 files changed, 115 deletions(-)
>  delete mode 100644 
> meta/recipes-core/busybox/busybox/0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch
>
> diff --git 
> a/meta/recipes-core/busybox/busybox/0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch
>  
> b/meta/recipes-core/busybox/busybox/0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch
> deleted file mode 100644
> index 2bf2b91c7e..00
> --- 
> a/meta/recipes-core/busybox/busybox/0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch
> +++ /dev/null
> @@ -1,114 +0,0 @@
> -From a9333eb6a7b8dbda735947cd5bc981ff9352a2c9 Mon Sep 17 00:00:00 2001
> -From: Nathan Phillip Brink 
> -Date: Thu, 10 Mar 2011 00:27:08 -0500
> -Subject: [PATCH 1/2] Use $(CC) when linking instead of $(LD) and use 
> $(CFLAGS)
> - and $(EXTRA_CFLAGS) when linking.
> -
> -This fixes the issue where LDFLAGS escaped with -Wl are ignored during
> -compilation. It also simplifies using CFLAGS or EXTRA_CFLAGS (such as
> --m32 on x86_64 or -flto) which apply to both compilation and linking
> -situations.
> -
> -Signed-off-by: Nathan Phillip Brink 
> 
> -Upstream-Status: Pending
> -
> - Makefile   |  7 ---
> - scripts/Makefile.build |  8 
> - scripts/Makefile.lib   | 13 +++--
> - 3 files changed, 11 insertions(+), 17 deletions(-)
> -
> -Index: busybox-1.23.2/Makefile
> -===
>  busybox-1.23.2.orig/Makefile
> -+++ busybox-1.23.2/Makefile
> -@@ -309,7 +309,8 @@ CHECKFLAGS := -D__linux__ -Dlinux -D
> - MODFLAGS  = -DMODULE
> - CFLAGS_MODULE   = $(MODFLAGS)
> - AFLAGS_MODULE   = $(MODFLAGS)
> --LDFLAGS_MODULE  = -r
> -+LDFLAGS_RELOCATABLE = -r -nostdlib
> -+LDFLAGS_MODULE  = $(LDFLAGS_RELOCATABLE)
> - CFLAGS_KERNEL =
> - AFLAGS_KERNEL =
> -
> -@@ -331,7 +332,7 @@ KERNELVERSION = $(VERSION).$(PATCHLEVEL)
> - exportVERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION \
> -   ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \
> -   CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE \
> --  HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
> -+  HOSTCXX HOSTCXXFLAGS LDFLAGS_RELOCATABLE LDFLAGS_MODULE CHECK 
> CHECKFLAGS
> -
> - export CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
> - export CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
> -@@ -610,7 +611,7 @@ quiet_cmd_busybox__ ?= LINK$@
> -   cmd_busybox__ ?= $(srctree)/scripts/trylink \
> -   "$@" \
> -   "$(CC)" \
> --  "$(CFLAGS) $(CFLAGS_busybox)" \
> -+  "$(CFLAGS) $(CFLAGS_busybox) $(EXTRA_CFLAGS)" \
> -   "$(LDFLAGS) $(EXTRA_LDFLAGS)" \
> -   "$(core-y)" \
> -   "$(libs-y)" \
> -Index: busybox-1.23.2/scripts/Makefile.build
> -===
>  busybox-1.23.2.orig/scripts/Makefile.build
> -+++ busybox-1.23.2/scripts/Makefile.build
> -@@ -174,7 +174,7 @@ cmd_modversions =
>   \
> -   | $(GENKSYMS) -a $(ARCH)\
> -   > $(@D)/.tmp_$(@F:.o=.ver); \
> -   \
> --  $(LD) $(LDFLAGS) -r -o $@ $(@D)/.tmp_$(@F)  \
> -+   $(CC) $(ld_flags_partial) $(LDFLAGS_RELOCATABLE) -o $@ 
> $(@D)/.tmp_$(@F)\
> -   -T $(@D)/.tmp_$(@F:.o=.ver);\
> -   rm -f $(@D)/.tmp_$(@F) $(@D)/.tmp_$(@F:.o=.ver);\
> -   else\
> -@@ -257,7 +257,7 @@ quiet_cmd_link_o_target = LD  $@
> - # If the list of objects to link is empty, just create an empty built-in.o
> - # -nostdlib is added to make "make LD=gcc ..." work (some people use that)
> - cmd_link_o_target = $(if $(strip $(obj-y)),\
> --  $(LD) -nostdlib $(ld_flags) -r -o $@ $(filter $(obj-y), $^),\
> -+  $(CC) $(ld_flags_partial) $(LDFLAGS_RELOCATABLE) -o $@ 
> $(filter $(obj-y), $^),\
> -   rm -f $@; $(AR) rcs $@)
> -
> - 

Re: [OE-core] [PATCH] recipe-graphics: Add depends on cmake-native

2021-11-10 Thread Andre McCurdy
On Wed, Nov 10, 2021 at 5:41 PM Peter Kjellerstedt
 wrote:
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org 
> >  On Behalf Of Anibal Limon
> > Sent: den 11 november 2021 01:44
> > To: openembedded-core@lists.openembedded.org
> > Cc: richard.pur...@linuxfoundation.org; Aníbal Limón 
> > 
> > Subject: [OE-core] [PATCH] recipe-graphics: Add depends on cmake-native
>
> Change "recipe-graphics" to "waffle".
>
> //Peter
>
> >
> > Fixes,
> >
> > ...
> >   File 
> > "/home/builds/oe-rpb-master/build-410c/tmp-rpb-glibc/work/cortexa53-linaro-linux/waffle/1.7.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/mesonbuild/modules/cmake.py",
> >  line 241, in detect_cmake
> > p, stdout, stderr = mesonlib.Popen_safe(cmakebin.get_command() + 
> > ['--system-information', '-G', 'Ninja'])[0:3]
> >   File 
> > "/home/builds/oe-rpb-master/build-410c/tmp-rpb-glibc/work/cortexa53-linaro-linux/waffle/1.7.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/mesonbuild/mesonlib/universal.py",
> >  line 1397, in Popen_safe
> > p = subprocess.Popen(args, universal_newlines=True, close_fds=False,
> >   File 
> > "/home/builds/oe-rpb-master/build-410c/tmp-rpb-glibc/work/cortexa53-linaro-linux/waffle/1.7.0-r0/recipe-sysroot-native/usr/lib/python3.10/subprocess.py",
> >  line 966, in __init__
> > self._execute_child(args, executable, preexec_fn, close_fds,
> >   File 
> > "/home/builds/oe-rpb-master/build-410c/tmp-rpb-glibc/work/cortexa53-linaro-linux/waffle/1.7.0-r0/recipe-sysroot-native/usr/lib/python3.10/subprocess.py",
> >  line 1717, in _execute_child
> > and os.path.dirname(executable)
> >   File 
> > "/home/builds/oe-rpb-master/build-410c/tmp-rpb-glibc/work/cortexa53-linaro-linux/waffle/1.7.0-r0/recipe-sysroot-native/usr/lib/python3.10/posixpath.py",
> >  line 152, in dirname
> > p = os.fspath(p)
> > ...
> >
> > Signed-off-by: Aníbal Limón 
> > ---
> >  meta/recipes-graphics/waffle/waffle_1.7.0.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-graphics/waffle/waffle_1.7.0.bb 
> > b/meta/recipes-graphics/waffle/waffle_1.7.0.bb
> > index 6284af3076..ea11309940 100644
> > --- a/meta/recipes-graphics/waffle/waffle_1.7.0.bb
> > +++ b/meta/recipes-graphics/waffle/waffle_1.7.0.bb
> > @@ -17,7 +17,7 @@ S = "${WORKDIR}/git"
> >
> >  inherit meson features_check lib_package bash-completion pkgconfig
> >
> > -DEPENDS:append = " python3"
> > +DEPENDS:append = " python3 cmake-native"

It's unusual for a recipe to add cmake-native to DEPENDS rather than
inheriting the cmake class. Your patch comments should probably
explain why it's the correct approach.

> >  # This should be overridden per-machine to reflect the capabilities of the 
> > GL
> >  # stack.
> > --
> > 2.33.1
>
>
> 
>

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



Re: [OE-core] [PATCH 1/5] mirrors.bbclass: Clean up the additions to MIRRORS

2021-11-10 Thread Andre McCurdy
On Wed, Nov 10, 2021 at 3:19 PM Peter Kjellerstedt
 wrote:
>
> * Since commit ce0579dc in bitbake (fetch2: Revert the regexp removal
>   for the type field and instead anchor regexp) the type regexp has
>   been automatically anchored at the end.
> * Since commit 044fb04d in bitbake (fetch2: Allow whitespace only mirror
>   entries) there is no need to separate the entries in MIRRORS with "\n".
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta/classes/mirrors.bbclass | 134 +--
>  1 file changed, 67 insertions(+), 67 deletions(-)
>
> diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass
> index 08abcce52c..dc95cc1174 100644
> --- a/meta/classes/mirrors.bbclass
> +++ b/meta/classes/mirrors.bbclass
> @@ -1,75 +1,75 @@
>  MIRRORS += "\
> -${DEBIAN_MIRROR}   
> http://snapshot.debian.org/archive/debian/20180310T215105Z/pool \n \
> -${DEBIAN_MIRROR}   
> http://snapshot.debian.org/archive/debian-archive/20120328T092752Z/debian/pool
>  \n \
> -${DEBIAN_MIRROR}   
> http://snapshot.debian.org/archive/debian-archive/20110127T084257Z/debian/pool
>  \n \
> -${DEBIAN_MIRROR}   
> http://snapshot.debian.org/archive/debian-archive/20090802T004153Z/debian/pool
>  \n \
> -${DEBIAN_MIRROR}   http://ftp.de.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.au.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.cl.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.hr.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.fi.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.hk.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.hu.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.ie.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.it.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.jp.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.no.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.pl.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.ro.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.si.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.es.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.se.debian.org/debian/pool \n \
> -${DEBIAN_MIRROR}   http://ftp.tr.debian.org/debian/pool \n \
> -${GNU_MIRROR}  https://mirrors.kernel.org/gnu \n \
> -${KERNELORG_MIRROR}http://www.kernel.org/pub \n \
> -${GNUPG_MIRROR}ftp://ftp.gnupg.org/gcrypt \n \
> -${GNUPG_MIRROR}
> ftp://ftp.franken.de/pub/crypt/mirror/ftp.gnupg.org/gcrypt \n \
> -${GNUPG_MIRROR}ftp://mirrors.dotsrc.org/gcrypt \n \
> -ftp://dante.ctan.org/tex-archive ftp://ftp.fu-berlin.de/tex/CTAN \n \
> -ftp://dante.ctan.org/tex-archive http://sunsite.sut.ac.jp/pub/archives/ctan/ 
> \n \
> -ftp://dante.ctan.org/tex-archive http://ctan.unsw.edu.au/ \n \
> -ftp://ftp.gnutls.org/gcrypt/gnutls ${GNUPG_MIRROR}/gnutls \n \
> -http://ftp.info-zip.org/pub/infozip/src/ 
> ftp://sunsite.icm.edu.pl/pub/unix/archiving/info-zip/src/ \n \
> -http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/ 
> http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/
>  \n \
> -${APACHE_MIRROR}  http://www.us.apache.org/dist \n \
> -${APACHE_MIRROR}  http://archive.apache.org/dist \n \
> -http://downloads.sourceforge.net/watchdog/ http://fossies.org/linux/misc/ \n 
> \
> -${SAVANNAH_GNU_MIRROR} http://download-mirror.savannah.gnu.org/releases \n \
> -${SAVANNAH_NONGNU_MIRROR} 
> http://download-mirror.savannah.nongnu.org/releases \n \
> -ftp://sourceware.org/pub http://mirrors.kernel.org/sourceware \n \
> -ftp://sourceware.org/pub http://gd.tuwien.ac.at/gnu/sourceware \n \
> -ftp://sourceware.org/pub 
> http://ftp.gwdg.de/pub/linux/sources.redhat.com/sourceware \n \
> -cvs://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
> -svn://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
> -git://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
> -hg://.*/.*  http://downloads.yoctoproject.org/mirror/sources/ \n \
> -bzr://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
> -p4://.*/.*  http://downloads.yoctoproject.org/mirror/sources/ \n \
> -osc://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
> -https?$://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
> -ftp://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \
> -npm://.*/?.*http://downloads.yoctoproject.org/mirror/sources/ \n \
> -cvs://.*/.* http://sources.openembedded.org/ \n \
> -svn://.*/.* http://sources.openembedded.org/ \n \
> -git://.*/.* http://sources.openembedded.org/ \n \
> -hg://.*/.*  http://sources.openembedded.org/ \n \
> -bzr://.*/.* http://sources.openembedded.org/ \n \
> -p4://.*/.*  http://sources.openembedded.org/ \n \
> -osc://.*/.*  

Re: [OE-core] [PATCH 3/5] gcc-common.inc: Clean up the additions to MIRRORS

2021-11-10 Thread Andre McCurdy
On Wed, Nov 10, 2021 at 3:19 PM Peter Kjellerstedt
 wrote:
>
> Since commit 044fb04d in bitbake (fetch2: Allow whitespace only mirror
> entries) there is no need to separate the entries in MIRRORS with "\n".
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta/recipes-devtools/gcc/gcc-common.inc | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-common.inc 
> b/meta/recipes-devtools/gcc/gcc-common.inc
> index 74190644e6..0d950e780d 100644
> --- a/meta/recipes-devtools/gcc/gcc-common.inc
> +++ b/meta/recipes-devtools/gcc/gcc-common.inc
> @@ -86,11 +86,11 @@ get_tune_parameters[vardepsexclude] = "AVAILTUNES 
> TUNE_CCARGS OVERRIDES TUNE_FEA
>  DEBIANNAME:${MLPREFIX}libgcc = "libgcc1"
>
>  MIRRORS =+ "\
> -${GNU_MIRROR}/gccftp://gcc.gnu.org/pub/gcc/releases/ \n \
> -${GNU_MIRROR}/gcc  ftp://gd.tuwien.ac.at/gnu/gcc/ \n \
> -${GNU_MIRROR}/gcc  http://mirrors.rcn.net/pub/sourceware/gcc/releases/ 
> \n \
> -${GNU_MIRROR}/gcc   http://gcc.get-software.com/releases/ \n \
> -${GNU_MIRROR}/gcc  http://gcc.get-software.com/releases/ \n \
> +${GNU_MIRROR}/gcc ftp://gcc.gnu.org/pub/gcc/releases/ \
> +${GNU_MIRROR}/gcc ftp://gd.tuwien.ac.at/gnu/gcc/ \
> +${GNU_MIRROR}/gcc http://mirrors.rcn.net/pub/sourceware/gcc/releases/ \
> +${GNU_MIRROR}/gcc http://gcc.get-software.com/releases/ \
> +${GNU_MIRROR}/gcc http://gcc.get-software.com/releases/ \

Last two lines are duplicates. ftp mirrors should probably be replaced
with https.

Are these even useful at all? They were added in 2012...

>  "
>  #
>  # Set some default values
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#158127): 
https://lists.openembedded.org/g/openembedded-core/message/158127
Mute This Topic: https://lists.openembedded.org/mt/86970465/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] meta: use ln -rs instead of lnr

2021-11-10 Thread Andre McCurdy
On Wed, Nov 10, 2021 at 3:12 AM Ross Burton  wrote:
>
> lnr is a script in oe-core that creates relative symlinks, with the same
> behaviour as `ln --relative --symlink`.  It was added back in 2014[1] as
> not all of the supported host distributions at the time shipped
> coreutils 8.16, the first release with --relative.
>
> However the oldest coreutils release in the supported distributions is
> now 8.22 in CentOS 7, so lnr can be deprecated and users switched to ln.
>
> [1] 6ae3b85eaffd1b0b6914422e8de7c1230723157d
>
> Signed-off-by: Ross Burton 
> ---
>  meta/classes/image.bbclass | 10 +-
>  meta/classes/populate_sdk_ext.bbclass  |  4 ++--
>  meta/recipes-core/glibc/glibc-package.inc  |  4 ++--
>  .../images/build-appliance-image_15.0.0.bb |  2 +-
>  meta/recipes-core/musl/gcompat_git.bb  |  2 +-
>  meta/recipes-core/musl/musl_git.bb |  2 +-
>  meta/recipes-core/ncurses/ncurses.inc  |  4 ++--
>  meta/recipes-core/os-release/os-release.bb |  2 +-
>  meta/recipes-devtools/dnf/dnf_4.10.0.bb|  4 ++--
>  meta/recipes-devtools/pkgconf/pkgconf_1.8.0.bb |  2 +-
>  meta/recipes-devtools/pkgconfig/pkgconfig_git.bb   |  2 +-
>  meta/recipes-kernel/kmod/kmod_git.bb   |  4 ++--
>  meta/recipes-kernel/linux/kernel-devsrc.bb |  2 +-
>  13 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 2fa69a40d1..6c759fdf70 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -622,20 +622,20 @@ deltask do_package_write_rpm
>  create_merged_usr_symlinks() {
>  root="$1"
>  install -d $root${base_bindir} $root${base_sbindir} $root${base_libdir}
> -lnr $root${base_bindir} $root/bin
> -lnr $root${base_sbindir} $root/sbin
> -lnr $root${base_libdir} $root/${baselib}
> +ln -rs $root${base_bindir} $root/bin
> +ln -rs $root${base_sbindir} $root/sbin
> +ln -rs $root${base_libdir} $root/${baselib}
>
>  if [ "${nonarch_base_libdir}" != "${base_libdir}" ]; then
> install -d $root${nonarch_base_libdir}
> -   lnr $root${nonarch_base_libdir} $root/lib
> +   ln -rs $root${nonarch_base_libdir} $root/lib
>  fi
>
>  # create base links for multilibs
>  multi_libdirs="${@d.getVar('MULTILIB_VARIANTS')}"
>  for d in $multi_libdirs; do
>  install -d $root${exec_prefix}/$d
> -lnr $root${exec_prefix}/$d $root/$d
> +ln -rs $root${exec_prefix}/$d $root/$d
>  done
>  }
>
> diff --git a/meta/classes/populate_sdk_ext.bbclass 
> b/meta/classes/populate_sdk_ext.bbclass
> index 9187f53f13..ef93b6a826 100644
> --- a/meta/classes/populate_sdk_ext.bbclass
> +++ b/meta/classes/populate_sdk_ext.bbclass
> @@ -626,7 +626,7 @@ install_tools() {
> for script in $scripts; do
> for scriptfn in `find 
> ${SDK_OUTPUT}/${SDKPATH}/${scriptrelpath} -maxdepth 1 -executable -name 
> "$script"`; do
> 
> targetscriptfn="${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}/$(basename 
> $scriptfn)"
> -   test -e ${targetscriptfn} || lnr ${scriptfn} 
> ${targetscriptfn}
> +   test -e ${targetscriptfn} || ln -rs ${scriptfn} 
> ${targetscriptfn}
> done
> done
> # We can't use the same method as above because files in the sysroot 
> won't exist at this point
> @@ -634,7 +634,7 @@ install_tools() {
> unfsd_path="${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}/unfsd"
> if [ "${SDK_INCLUDE_TOOLCHAIN}" = "1" -a ! -e $unfsd_path ] ; then
> 
> binrelpath=${@os.path.relpath(d.getVar('STAGING_BINDIR_NATIVE'), 
> d.getVar('TMPDIR'))}
> -   lnr ${SDK_OUTPUT}/${SDKPATH}/tmp/$binrelpath/unfsd $unfsd_path
> +   ln -rs ${SDK_OUTPUT}/${SDKPATH}/tmp/$binrelpath/unfsd 
> $unfsd_path
> fi
> touch ${SDK_OUTPUT}/${SDKPATH}/.devtoolbase
>
> diff --git a/meta/recipes-core/glibc/glibc-package.inc 
> b/meta/recipes-core/glibc/glibc-package.inc
> index 571ae7ae09..54e2a08906 100644
> --- a/meta/recipes-core/glibc/glibc-package.inc
> +++ b/meta/recipes-core/glibc/glibc-package.inc
> @@ -119,8 +119,8 @@ do_install() {
> ln -s ${@oe.path.relative('${root_prefix}/lib', 
> '${base_libdir}')}/${ARCH_DYNAMIC_LOADER} \
> ${D}${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}
> fi
> -lnr ${D}${base_libdir}/libpthread.so.0 ${D}${libdir}/libpthread.so
> -lnr ${D}${base_libdir}/librt.so.1 ${D}${libdir}/librt.so
> +ln -rs ${D}${base_libdir}/libpthread.so.0 ${D}${libdir}/libpthread.so
> +ln -rs ${D}${base_libdir}/librt.so.1 ${D}${libdir}/librt.so
>  }
>
>  def get_libc_fpu_setting(bb, d):
> diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb 
> 

Re: [OE-core] Depending on other package's config

2021-11-05 Thread Andre McCurdy
On Fri, Nov 5, 2021 at 3:25 PM Maxim Sloyko via lists.openembedded.org
 wrote:
>
> Hi all,
>
> Posting this to openembedded-core, as it was suggested to me.
>
> The recipe that I'm working on for our system (let's call it A) has a
> dependency on a certain feature being enabled in another package (B).
> So, in B, we have:
>
> PACKAGECONFIG[nice-feature] = "..."
>
> and my recipe (or rather, the tool built by the recipe), needs that
> feature to be enabled to work properly. What's worse, is that this is
> a runtime dependency, so if somebody just forgets to enable that
> feature, the image will build fine, but the tool won't work. I would
> like this to be a build time failure.
>
> My plan is to change recipe A, so that if the "nice-feature" is
> enabled, the package will PROVIDE one more thing:
>
> PROVIDES += "${PN}-nice-feature"
>
> and in my recipe B, I'll declare this as a dependency:
>
> RDEPENDS:${PN} += "package-a-nice-feature".

You're doing that just to generate a build time error if the two
recipe's configurations are not consistent?

The normal approach would be to define a global variable (e.g. a
distro feature) which both recipes can check and use to configure
themselves appropriately.

> Now I'm thinking, wouldn't it be great if package A could specify
> extra PROVIDES when the feature is configured? This would be similar
> to the way it's done for package's R?DEPENDS:
>
> PACKAGECONFIG ??= "f1 f2 f3 ..."
>  PACKAGECONFIG[f1] = "\
>   --with-f1, \
>   --without-f1, \
>   build-deps-for-f1, \
>   runtime-deps-for-f1, \
>   runtime-recommends-for-f1, \
>   packageconfig-conflicts-for-f1 \
>   provides-for-f1 \
>   "
>
> The last line would be a change that I propose. It looks like it would
> be relatively easy to implement this in base.bbclass
>
> What do you think? Will this be useful? Did I miss an existing way to do this?
>
> Thanks,
>
> --
> -MS
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157931): 
https://lists.openembedded.org/g/openembedded-core/message/157931
Mute This Topic: https://lists.openembedded.org/mt/86853514/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] simplest use of SSTATE_MIRRORS?

2021-09-27 Thread Andre McCurdy
On Mon, Sep 27, 2021 at 9:13 AM Robert P. J. Day  wrote:
>
>   colleague asked me how SSTATE_MIRRORS worked, so i had to check,
> followed the section here:
>
> http://docs.yoctoproject.org/overview-manual/concepts.html#shared-state-cache
>
> and in one of own builds, i moved the entire sstate-cache directory
> to ~/SSTATE as is, then added the following to my site.conf:
>
> SSTATE_MIRRORS = " \
> file://.\* file:///home/rpjday/SSTATE/PATH \
> "

The example in local.conf.sample uses file://.* rather than file://.\*

>   then i removed all of /tmp in my current build, and re-ran my
> bitbake command, but it seems to be doing all the standard fetching
> and unpacking and so on. what clearly trivial step have i overlooked?
>
> rday
>
> p.s. i checked with "bitbake -e" that that variable seems to have the
> correct value. what silliness have i done?
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156398): 
https://lists.openembedded.org/g/openembedded-core/message/156398
Mute This Topic: https://lists.openembedded.org/mt/85904527/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] minor curiosity related to libdir vs base_libdir and shared libs

2021-09-07 Thread Andre McCurdy
On Sun, Sep 5, 2021 at 1:02 PM Robert P. J. Day  wrote:
>   a minor oddity i stumbled over digging into the proper installation
> of shared libraries ... building core-image-minimal for qemuarm64 and,
> for the most part, recipes from oe-core that install shared libs put
> all three artifacts (real name, so name and linker name) under
> /usr/lib, as in:
>
>   ./libtirpc/1.3.2-r0/image/usr/lib/libtirpc.so
>   ./libtirpc/1.3.2-r0/image/usr/lib/libtirpc.so.3
>   ./libtirpc/1.3.2-r0/image/usr/lib/libtirpc.so.3.0.0
>
> however, the *occasional* recipe chooses to -- for whatever reason --
> distinguish between libdir and base_libdir. for example, here's the
> result of installing tcp-wrappers' shared libs in its ${D} directory:
>
>   ./tcp-wrappers/7.6-r10/image/lib/libwrap.so.0.7.6
>   ./tcp-wrappers/7.6-r10/image/lib/libwrap.so.0
>   ./tcp-wrappers/7.6-r10/image/usr/lib/libwrap.so
>
> this is due to the following manual override in tcp-wrappers_7.6.bb:
>
>   do_install () {
> oe_libinstall -a libwrap ${D}${libdir}
> oe_libinstall -C shared -so libwrap ${D}${base_libdir}
>
> if [ "${libdir}" != "${base_libdir}" ] ; then
> rel_lib_prefix=`echo ${libdir} | sed 
> 's,\(^/\|\)[^/][^/]*,..,g'`
> libname=`readlink ${D}${base_libdir}/libwrap.so | xargs 
> basename`
> ln -s ${rel_lib_prefix}${base_libdir}/${libname} 
> ${D}${libdir}/libwrap.so
> rm -f ${D}${base_libdir}/libwrap.so
> fi
> ...
>
> so this recipe -- after doing the *default* shared lib installation
> via oe_libinstall() -- conditionally chooses to override that.

git blame is often the best starting point for understanding why
things are done in a certain way. In this case the comment from the
original comment (from 11 years ago..) references portmap, which is no
longer supported by oe-core:

  
https://git.openembedded.org/openembedded-core/commit/?id=6ffc4f2e04f2d405b14f198220a3613d386489e7

>   another recipe that is even odder is libcap-ng:
>
>   ./libcap-ng/0.8.2-r0/image/lib/libcap-ng.so.0.0.0
>   ./libcap-ng/0.8.2-r0/image/lib/libcap-ng.so.0
>   ./libcap-ng/0.8.2-r0/image/usr/lib/libcap-ng.so
>   ./libcap-ng/0.8.2-r0/image/usr/lib/libdrop_ambient.so.0
>   ./libcap-ng/0.8.2-r0/image/usr/lib/libdrop_ambient.so
>   ./libcap-ng/0.8.2-r0/image/usr/lib/libdrop_ambient.so.0.0.0
>
> which seems odd since it does that override for *one* of the shared
> libs that it generates, but not the other:
>
>   do_install:append() {
> # Moving libcap-ng to base_libdir
> if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
> mkdir -p ${D}/${base_libdir}/
> mv -f ${D}${libdir}/libcap-ng.so.* ${D}${base_libdir}/
> relpath=${@os.path.relpath("${base_libdir}", "${libdir}")}
> ln -sf ${relpath}/libcap-ng.so.0.0.0 
> ${D}${libdir}/libcap-ng.so
> fi
>   }

The original commit from 2013 gives a few more clues in this case:

  
https://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=587fdba43a7747992995029a88d3051ef0efe7f6

It's not explicit which QA test was being triggered but presumably it
was "unsafe-references-in-binaries", which has since been dropped from
oe-core:

  
https://git.openembedded.org/openembedded-core/commit/?id=a6af5bbf3dad6f0951c67a0aae13ef86a8906893

So... it looks like these examples of moving libs to base_libdir are
obsolete and can be dropped.

Some comments in insane.bbclass left behind when the
unsafe-references-in-binaries and unsafe-references-in-scripts QA
tests were removed can be dropped too.

> given that almost all other recipes seem happy to just stuff all that
> under /usr/lib, what is the rationale for the above occasional
> difference? it pretty clearly doesn't affect functionality; it just
> looks strange.
>
> rday
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155743): 
https://lists.openembedded.org/g/openembedded-core/message/155743
Mute This Topic: https://lists.openembedded.org/mt/85398874/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] bitbake.conf: update way of setting XZ_MEMLIMIT

2021-08-24 Thread Andre McCurdy
On Tue, Aug 24, 2021 at 7:15 AM Richard Purdie
 wrote:
>
> On Tue, 2021-08-24 at 17:40 +0800, Changqing Li wrote:
> > From: Changqing Li 
> >
> > Update way of setting XZ_MEMLIMIT, considering scenario that
> > running bitbake in container, to avoid OOM Killer of xz.
> >
> > For example:
> > Container has memory limit of 30G, and host memory is 300G.  'xz
> > --memlimit=50% ...' will get host memory, so the limit for xz is 150G.
> > And because of the container memory limit is 30G, xz can use nearly up
> > to 30G memory, which may cause oom kill of xz.
> >
> > Signed-off-by: Changqing Li 
> > ---
> >  meta/conf/bitbake.conf |  3 ++-
> >  meta/lib/oe/utils.py   | 12 
> >  2 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index f6fb2aa698..2b36e083ca 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -809,7 +809,8 @@ BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
> >  PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
> >
> >  # Default parallelism and resource usage for xz
> > -XZ_MEMLIMIT ?= "50%"
> > +CONTAINER_MEM_LIMIT = "${@oe.utils.container_mem_limit()}"
> > +XZ_MEMLIMIT ?= "${@ '%d' % (int(d.getVar('CONTAINER_MEM_LIMIT'))/2) if 
> > d.getVar('CONTAINER_MEM_LIMIT') != '0' else '50%'}"
> >  XZ_THREADS ?= "${@oe.utils.cpu_count(at_least=2)}"
> >  XZ_DEFAULTS ?= "--memlimit=${XZ_MEMLIMIT} --threads=${XZ_THREADS}"
> >  XZ_DEFAULTS[vardepsexclude] += "XZ_MEMLIMIT XZ_THREADS"
> > diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
> > index a84039f585..581072ac0d 100644
> > --- a/meta/lib/oe/utils.py
> > +++ b/meta/lib/oe/utils.py
> > @@ -252,6 +252,18 @@ def cpu_count(at_least=1):
> >  cpus = len(os.sched_getaffinity(0))
> >  return max(cpus, at_least)
> >
> > +def container_mem_limit():
> > +limit_in_bytes = '0'
> > +proc_sched = '/proc/1/sched'
> > +if os.path.exists(proc_sched):
> > +with open(proc_sched, 'r') as fp:
> > +initinfo = fp.readline().strip()
> > +cgroup_limit_in_bytes = 
> > '/sys/fs/cgroup/memory/memory.limit_in_bytes'
> > +if initinfo.split(' ')[0] not in ('systemd', 'init',) and 
> > os.path.exists(cgroup_limit_in_bytes):
> > +with open(cgroup_limit_in_bytes) as fpc:
> > +limit_in_bytes=fpc.readline().strip()
> > +return limit_in_bytes
> > +
>
> Whilst I understand the idea here, this is an awful lot of hardcoded values 
> and
> "magic". I'm not sure we want all bitbake processes to be making these kinds 
> of
> queries/decisions every time the config is parsed...

I'm sure this was discussed before but I forget the answer... how much
compression / performance is lost by setting the XZ memory limit to a
fixed value which is reasonable for all systems (e.g. 1GB? 256MB *
XZ_THREADS?).

As well as making the code simpler should also make builds more
reproducible by not depending on some detail which is specific to the
host (ie total memory size).

> Adding the function to oe/utils may be ok but I'm not keen on making it the
> default.
>
> Cheers,
>
> Richard
>
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155266): 
https://lists.openembedded.org/g/openembedded-core/message/155266
Mute This Topic: https://lists.openembedded.org/mt/85107112/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] vim: add option to disable NLS support

2021-08-23 Thread Andre McCurdy
On Mon, Aug 23, 2021 at 10:12 AM Andrej Valek  wrote:
>
> Hello Khem,
>
> I looked exactly into configure.ac which arguments are expecting for those 
> options. So I think, it has to be mentioned explicitly.

Assuming configure.ac is based around AC_ARG_ENABLE / AC_ARG_WITH then
an explicit option is not required. A default value of "yes" will be
set for --enable-foo / --with-foo and a default value of "no" will be
set for --disable-foo / --without-foo.

However, apart from that, you've also dropped the leaving "--" from
various --enable-foo options and converted dashes to underscores, all
of which looks wrong. How were the changes tested?

> Regards,
> Andrej
>
> > On 8/23/21 3:12 AM, Andrej Valek wrote:
> >> - Some distributions with UTF-8 locale have problem when National Language
> >>   Support is enabled. Add there an option to disable it.
> >> - refresh options based on configure.ac
> >>
> >> Signed-off-by: Andrej Valek 
> >> ---
> >>   meta/recipes-support/vim/vim.inc | 8 +---
> >>   1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/meta/recipes-support/vim/vim.inc
> >> b/meta/recipes-support/vim/vim.inc
> >> index 17d1c24a7c..7cc47884f2 100644
> >> --- a/meta/recipes-support/vim/vim.inc
> >> +++ b/meta/recipes-support/vim/vim.inc
> >> @@ -54,19 +54,21 @@ do_compile() {
> >>   autotools_do_compile
> >>   }
> >>
> >> -#Available PACKAGECONFIG options are gtkgui, acl, x11, tiny
> >> +#Available PACKAGECONFIG options are gtkgui, acl, x11, tiny, selinux,
> >> +elfutils, nls
> >>   PACKAGECONFIG ??= ""
> >>   PACKAGECONFIG += " \
> >>   ${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)} \
> >>   ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 gtkgui', '',
> >> d)} \
> >> +nls \
> >>   "
> >>
> >>   PACKAGECONFIG[gtkgui] = "--enable-gui=gtk3,--enable-gui=no,gtk+3"
> >> -PACKAGECONFIG[acl] = "--enable-acl,--disable-acl,acl,"
> >> +PACKAGECONFIG[acl] = "enable_acl="yes",--disable-acl,acl,"
> >
> >is 'yes' needed to be explicit ? I thought --enable-XYZ meant it implicitly
> >
> >>   PACKAGECONFIG[x11] = "--with-x,--without-x,xt,"
> >>   PACKAGECONFIG[tiny] = "--with-features=tiny,--with-features=big,,"
> >> -PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux,"
> >> +PACKAGECONFIG[selinux] = 
> >> "enable_selinux="yes",--disable-selinux,libselinux,"
> >>   PACKAGECONFIG[elfutils] = "--enable-elf-check,,elfutils,"
> >> +PACKAGECONFIG[nls] = "enable_nls="yes",--disable-nls,,"
> >>
> >>   EXTRA_OECONF = " \
> >>   --disable-gpm \
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155195): 
https://lists.openembedded.org/g/openembedded-core/message/155195
Mute This Topic: https://lists.openembedded.org/mt/85082071/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] would reducing BB_NUMBER_THREADS solve parallelism overheating?

2021-08-08 Thread Andre McCurdy
On Sat, Aug 7, 2021 at 8:26 AM Robert P. J. Day  wrote:
>
>   i've asked about this previously, but i finally got around to
> thinking about this in detail, and i'd like some feedback.
>
>   i've described the overheating/lockup issues i've been having on a
> dell latitude laptop building a sizable (wind river linux-based) image
> represented by 5-6000 tasks.
>
>   if i start the full build from scratch, it would take about 2 hours
> if it succeeded but, on a very regular basis, when the load average
> well exceeds 120 and i can feel really hot air blowing (even with t
> laptop cooler), the laptop will simply lock up hard.
>
>   the CPU is a i7-9850H, so 6 cores/12 threads, and i've refactored
> numerous proprietary in-house recipes to really crank up the
> parallelism so that, a lot of the time, i can see all 12 threads
> churning away on some task. of course, that's exactly when i get the
> huge load average/overheating/lockup.

Running all CPUs at 100% load shouldn't cause lockups unless there's a
HW problem. Another possible cause of lockups is using all available
DRAM (which is obviously related to how many simultaneous processes
are running too). On my laptop with 4 CPUs / 8 threads and 16GB DRAM I
have to manually over-ride BB_NUMBER_THREADS in order to keep the
system responsive and avoid running out of memory. The default
BB_NUMBER_THREADS / PARALLEL_MAKE are often too aggressive for laptops
etc running a desktop distro.

>   a couple colleagues suggested using BB_NUMBER_THREADS (BNT for
> short) to dial things back a bit but, after i pondered a bit, it seems
> that that would potentially make things worse, not better, so a couple
> questions about cores and threads.
>
>   first, given the CPU setup, let's say i set BNT to 6. does that mean
> 3 cores would be taken out of play entirely, leaving the other 3 to do
> all the work, or would each core simply use one thread, or who knows
> what would happen, and would any one scenario be superior to another?

The kernel will schedule processes to CPUs / SMT threads, not bitbake.
If you have exactly 6 processes to run then the kernel will most
likely schedule them on the 6 physical CPUs rather than 2 SMT threads
x 3 physical CPUs.

The only time the kernel might run 6 processes on 3 physical CPUs and
idle the other 3 would be if you enabled a power saving scheduler in
the kernel, but that behaviour wouldn't be the default.

>   my other realization(?) is that reducing BNT might be the *worst*
> strategy, and here's why. if i have a huge load average, that suggests
> i have lots and lots of tasks waiting to run (lots of stuff on the
> wait queue). but if i reduce the number of available threads, wouldn't
> that just force all that work to wait for a smaller number of threads,
> making the wait queues even longer?

No. If you reduce BB_NUMBER_THREADS then you reduce the number of
processes being added to the run queues, not the number of CPUs or SMT
threads which the kernel has available to execute them.

In summary, it sounds like reducing BB_NUMBER_THREADS is exactly what
you should do. It will reduce peak system load (ie the amount of heat
the system produces) and the peak DRAM usage (which may be the cause
of your lockups). Adding more DRAM (if it's not maxed out already)
might possibly solve the lockups too (but not the amount of heat).

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

2021-08-06 Thread Andre McCurdy
On Fri, Aug 6, 2021 at 7:12 AM Luca Boccassi  wrote:
>
> On Thu, 29 Jul 2021 at 20:11, Andre McCurdy  wrote:
> >
> > On Thu, Jul 29, 2021 at 6:49 AM Luca Bocassi  
> > wrote:
> > >
> > > Having a look at the patches, a few comments:
> > >
> > > - 0012-don-t-pass-AT_SYMLINK_NOFOLLOW-flag-to-faccessat.patch I find
> > > quite worrying, as it fundamentally changes access patterns, some of
> > > which are done for security reasons. At best, this will cause
> > > completely different runtime behaviours for the same filesystem
> > > depending on the libc implementation, which doesn't sound great?
> >
> > I wrote a long and verbose comment when I created the patch which
> > tries to document any differences in runtime behaviour.
> >
> >   
> >   Avoid using AT_SYMLINK_NOFOLLOW flag. It doesn't seem like the right 
> > thing to
> >   do and it's not portable (not supported by musl). See:
> >
> > 
> > http://lists.landley.net/pipermail/toybox-landley.net/2014-September/003610.html
> > http://www.openwall.com/lists/musl/2015/02/05/2
> >
> >   Note that laccess() is never passing AT_EACCESS so a lot of the 
> > discussion in
> >   the links above doesn't apply. Note also that (currently) all systemd 
> > callers
> >   of laccess() pass mode as F_OK, so only check for existence of a file, not
> >   access permissions. Therefore, in this case, the only distiction between
> >   faccessat() with (flag == 0) and (flag == AT_SYMLINK_NOFOLLOW) is the
> >   behaviour for broken symlinks; laccess() on a broken symlink will succeed
> >   with (flag == AT_SYMLINK_NOFOLLOW) and fail (flag == 0).
> >
> >   The laccess() macros was added to systemd some time ago and it's not 
> > clear if
> >   or why it needs to return success for broken symlinks. Maybe just 
> > historical
> >   and not actually necessary or desired behaviour?
> >   
> >
> > If that comment is now out of date or something is missing then please
> > send a patch to update it.
> >
> > However looking at this patch again now, it appears to have got broken
> > during a past rebase:
> >
> >   
> > https://git.openembedded.org/openembedded-core/commit/?id=e8dd5a36bf2f1e645fb2ff15eb3b5e97c04776e6
> >
> > The upstream code changed from:
> >
> >   #define laccess(path, mode) faccessat(AT_FDCWD, (path), (mode),
> > AT_SYMLINK_NOFOLLOW)
> >
> > to
> >
> >   #define laccess(path, mode) \
> >   (faccessat(AT_FDCWD, (path), (mode), AT_SYMLINK_NOFOLLOW) <
> > 0 ? -errno : 0)
> >
> > but the replacement version in the patch still returns the raw result
> > from faccessat(). That looks like an issue.
>
> If you think the flag is unnecessary (I don't, we use these for a
> reason, but that's not important right now), the correct action is to
> send a PR upstream to discuss removing it. Patching it out for one
> build case of many is just going to be a source of incompatibility and
> surprises for users, as the behaviour on the same filesystem changes
> depending on the build option. Having said that, I don't use musl so
> all of this is really not a problem for me, just providing some
> feedback as upstream maintainer, in case it can be useful.

I don't have any interest in systemd + musl anymore either. I did an
initial port as a proof of concept and sent patches to Khem off
list... and was somewhat surprised when they showed up some time later
in oe-core.

Note that there have been long discussions here previously about
whether OE should claim to support systemd + musl. The effort to
support it properly (including clarifying questions like this with
upstream as you suggest) doesn't seem huge but so far no one seems to
care enough about systemd + musl to do it. We rebase and tweak the
patches but guidance to potential users should still be "use at your
own risk".

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154573): 
https://lists.openembedded.org/g/openembedded-core/message/154573
Mute This Topic: https://lists.openembedded.org/mt/84490599/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] systemd-boot: use ld.bfd as efi-ld when gold is being used by default with ld-is-gold

2021-08-03 Thread Andre McCurdy
On Tue, Aug 3, 2021 at 12:04 PM Martin Jansa  wrote:
>
> * since the upgrade to 249.1 in:
>   
> https://git.openembedded.org/openembedded-core/commit/?id=323ec445dfe22860cd450c303db5ed8fcb4e791c
>   the builds with ld-is-gold are failing with:
>
>   [17/21] Generating linuxx64.elf.stub with a custom command
>   FAILED: src/boot/efi/linuxx64.elf.stub
>   
> /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/systemd-boot/249.1-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld
>  -o src/boot/efi/linuxx64.elf.stub -T 
> /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/systemd-boot/249.1-r0/recipe-sysroot/usr/lib/elf_x86_64_efi.lds
>  -shared -Bsymbolic -nostdlib -znocombreloc --build-id=sha1 -L 
> /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/systemd-boot/249.1-r0/recipe-sysroot/usr/lib
>  
> /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/systemd-boot/249.1-r0/recipe-sysroot/usr/lib/crt0-efi-x86_64.o
>  src/boot/efi/string-util-fundamental.c.o src/boot/efi/disk.c.o 
> src/boot/efi/graphics.c.o src/boot/efi/measure.c.o src/boot/efi/pe.c.o 
> src/boot/efi/secure-boot.c.o src/boot/efi/util.c.o src/boot/efi/linux.c.o 
> src/boot/efi/splash.c.o src/boot/efi/stub.c.o -lefi -lgnuefi 
> /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/systemd-boot/249.1-r0/recipe-sysroot/usr/lib/../lib/x86_64-oe-linux/11.2.0/libgcc.a
>   
> /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/systemd-boot/249.1-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld:
>  internal error in segment_precedes, at ../../gold/layout.cc:3721
>   [18/21] Generating boot.c.o with a custom command
>   ninja: build stopped: subcommand failed.
>   WARNING: exit code 1 from a shell command.
>
>   as reported in:
>   https://lists.openembedded.org/g/openembedded-core/message/154246
>
>   work around this by using ld.bfd when ld-is-gold is in DISTRO_FEATURES
>
> Signed-off-by: Martin Jansa 
> ---
>  meta/recipes-core/systemd/systemd-boot_249.1.bb | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/systemd/systemd-boot_249.1.bb 
> b/meta/recipes-core/systemd/systemd-boot_249.1.bb
> index d767b5bf8d..18f4fe55ce 100644
> --- a/meta/recipes-core/systemd/systemd-boot_249.1.bb
> +++ b/meta/recipes-core/systemd/systemd-boot_249.1.bb
> @@ -19,11 +19,13 @@ objcopy = ${@meson_array('OBJCOPY', d)}
>  EOF
>  }
>
> +EFI_LD = "${@d.getVar('LD').split()[0]}"
> +
>  EXTRA_OEMESON += "-Defi=true \
>-Dgnu-efi=true \
>-Defi-includedir=${STAGING_INCDIR}/efi \
>-Defi-libdir=${STAGING_LIBDIR} \
> -  -Defi-ld=${@ d.getVar('LD').split()[0]} \
> +  -Defi-ld=${@bb.utils.contains('DISTRO_FEATURES', 
> 'ld-is-gold', 'ld.bfd', '${EFI_LD}', d)} \

Could this just be set to ld.bfd in all cases?

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

2021-07-29 Thread Andre McCurdy
On Thu, Jul 29, 2021 at 6:49 AM Luca Bocassi  wrote:
>
> Having a look at the patches, a few comments:
>
> - 0012-don-t-pass-AT_SYMLINK_NOFOLLOW-flag-to-faccessat.patch I find
> quite worrying, as it fundamentally changes access patterns, some of
> which are done for security reasons. At best, this will cause
> completely different runtime behaviours for the same filesystem
> depending on the libc implementation, which doesn't sound great?

I wrote a long and verbose comment when I created the patch which
tries to document any differences in runtime behaviour.

  
  Avoid using AT_SYMLINK_NOFOLLOW flag. It doesn't seem like the right thing to
  do and it's not portable (not supported by musl). See:


http://lists.landley.net/pipermail/toybox-landley.net/2014-September/003610.html
http://www.openwall.com/lists/musl/2015/02/05/2

  Note that laccess() is never passing AT_EACCESS so a lot of the discussion in
  the links above doesn't apply. Note also that (currently) all systemd callers
  of laccess() pass mode as F_OK, so only check for existence of a file, not
  access permissions. Therefore, in this case, the only distiction between
  faccessat() with (flag == 0) and (flag == AT_SYMLINK_NOFOLLOW) is the
  behaviour for broken symlinks; laccess() on a broken symlink will succeed
  with (flag == AT_SYMLINK_NOFOLLOW) and fail (flag == 0).

  The laccess() macros was added to systemd some time ago and it's not clear if
  or why it needs to return success for broken symlinks. Maybe just historical
  and not actually necessary or desired behaviour?
  

If that comment is now out of date or something is missing then please
send a patch to update it.

However looking at this patch again now, it appears to have got broken
during a past rebase:

  
https://git.openembedded.org/openembedded-core/commit/?id=e8dd5a36bf2f1e645fb2ff15eb3b5e97c04776e6

The upstream code changed from:

  #define laccess(path, mode) faccessat(AT_FDCWD, (path), (mode),
AT_SYMLINK_NOFOLLOW)

to

  #define laccess(path, mode) \
  (faccessat(AT_FDCWD, (path), (mode), AT_SYMLINK_NOFOLLOW) <
0 ? -errno : 0)

but the replacement version in the patch still returns the raw result
from faccessat(). That looks like an issue.

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



Re: [OE-core] [PATCH 3/3] meta: Manual override fixes

2021-07-28 Thread Andre McCurdy
On Wed, Jul 28, 2021 at 1:54 PM Richard Purdie
 wrote:
>
> On Wed, 2021-07-28 at 13:43 -0700, Andre McCurdy wrote:
> > On Wed, Jul 28, 2021 at 1:24 PM Richard Purdie
> >  wrote:
> > >
> > > On Wed, 2021-07-28 at 21:00 +0100, Richard Purdie via 
> > > lists.openembedded.org wrote:
> > > > On Wed, 2021-07-28 at 12:32 -0700, Andre McCurdy wrote:
> > > > > On Wed, Jul 28, 2021 at 7:15 AM Richard Purdie
> > > > >  wrote:
> > > > > >
> > > > > > The automated conversion of OE-Core to use the new override sytax 
> > > > > > isn't
> > > > > > perfect. This patches some mis-converted lines and some lines which 
> > > > > > were missed
> > > > > > by the automation.
> > > > > >
> > > > > > Signed-off-by: Richard Purdie 
> > > > > > @@ -86,7 +86,7 @@ python systemd_populate_packages() {
> > > > > >  bb.debug(1, 'adding systemd calls to postinst/postrm for 
> > > > > > %s' % pkg)
> > > > > >
> > > > > >  paths_escaped = ' '.join(shlex.quote(s) for s in 
> > > > > > d.getVar('SYSTEMD_SERVICE:' + pkg).split())
> > > > > > -d.setVar('SYSTEMD_SERVICE:ESCAPED_' + pkg, paths_escaped)
> > > > > > +d.setVar('SYSTEMD_SERVICE_ESCAPED:' + pkg, paths_escaped)
> > > > >
> > > > > This is manually fixing the misconversion of _ESCAPED to :ESCAPED,
> > > > > right? If so then does it mean a bug in the automatic conversion
> > > > > script since overrides can't be uppercase?
> > > >
> > > > There are several bugs in the script, yes. The question is how far to go
> > > > in trying to address them and this wasn't a common issue.
> > >
> > > In case it isn't clear, this isn't as easy as you might first think. We 
> > > need
> > > to convert SYSTEMD_SERVICE_${PN} which has uppercase characters in it. 
> > > Can it
> > > be fixed? Probably, yes. Is it worth the effort/complexity? Maybe not.
> >
> > I haven't read the script but doesn't it distinguish between things
> > following an _ which might be an override (and will never be all
> > uppercase) and the variable name which is being overridden (which may
> > be uppercase)?
>
> The script is not a parser in any sense, it is looking for expressions using
> pattern matching and making changes based upon that. It is quite horrible in
> some ways, equally it is doing a reasonable job of the conversion on the most
> part too.
>
> > Since the script will be reused many times for many private layers I'd
> > say making it as robust as possible is a worthy goal.
>
> Well, sure. I have spent days on it and improved it several times over 
> compared
> to what it did do. I have it working for 10,000 cases in OE-Core with around 
> 40
> exceptions which I didn't think was too bad. I felt I'd reached the point of
> diminishing returns with it. As with most things, we can improve it and 
> patches
> are welcome.

Unfortunately those most affected by shortcomings in the script are
probably also those least likely to submit patches for it. Just as
those most affected by the new recipe syntax were probably not reading
oe-arch when you proposed the change and asked for feedback. They will
instead find out about it months or years from now when they discover
their meta layers don't work when they try using a new release of OE.
At that point a lot of them will just shug and keep on using 3.1
LTS...

> I'm more worried that the patterns of metadata in the wild may be quite 
> different
> to what we've trained the script with in OE-Core too, that may be a much more
> important issue.

Yes, that's a concern too. Looking at the script now it seems to be
mostly a long list of exceptions. The chances of it working well on
layers you haven't considered don't look too good.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154221): 
https://lists.openembedded.org/g/openembedded-core/message/154221
Mute This Topic: https://lists.openembedded.org/mt/84506029/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 pseudo 4/4] Do not return address of local variable

2021-07-28 Thread Andre McCurdy
On Wed, Jul 28, 2021 at 1:16 PM Seebs  wrote:
>
> On Wed, 28 Jul 2021 11:36:22 +0200
> "Damian Wrobel"  wrote:
>
> > Do I correctly assume that pseudo_client_op() has to be fully
> > reentrant?
>
> No. It's never been even a tiny bit reentrant. We used to do the
> allocate and free thing, and it was incredibly expensive, and the
> nature of the thing requires confidence that we never, ever, have
> more than one thing writing and reading over the socket at a time,
> so it's just Not Reentrant. During one call to pseudo_client_op,
> there will never be another, and all the IPC stuff uses a single
> consistent local buffer that it returns the address of.
>
> Declaring that as static without changing the initializer would indeed
> break everything -- we rely on the initializer working. Changing it to
> static means it only gets initialized once...
>
> Changing it to:
>
> static pseudo_msg_t msg;
> msg = pseudo_msg_t { .type = PSEUDO_MSG_OP };
>
> would probably be fine, because then it'd be initialized. Otherwise,
> we'd get failures when msg got overwritten and reused.
>
> Or just changing `result = ` to something like `result =
> _data`, which would be nonsensical but it turns out not to
> matter, as the only caller that reaches this case is the caller
> that's just checking yes/no "is the return value not a null pointer".

If the caller only cares about yes/no then how about returning 1/0
instead of a pointer?

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



Re: [OE-core] [PATCH 3/3] meta: Manual override fixes

2021-07-28 Thread Andre McCurdy
On Wed, Jul 28, 2021 at 1:24 PM Richard Purdie
 wrote:
>
> On Wed, 2021-07-28 at 21:00 +0100, Richard Purdie via lists.openembedded.org 
> wrote:
> > On Wed, 2021-07-28 at 12:32 -0700, Andre McCurdy wrote:
> > > On Wed, Jul 28, 2021 at 7:15 AM Richard Purdie
> > >  wrote:
> > > >
> > > > The automated conversion of OE-Core to use the new override sytax isn't
> > > > perfect. This patches some mis-converted lines and some lines which 
> > > > were missed
> > > > by the automation.
> > > >
> > > > Signed-off-by: Richard Purdie 
> > > > @@ -86,7 +86,7 @@ python systemd_populate_packages() {
> > > >  bb.debug(1, 'adding systemd calls to postinst/postrm for %s' % 
> > > > pkg)
> > > >
> > > >  paths_escaped = ' '.join(shlex.quote(s) for s in 
> > > > d.getVar('SYSTEMD_SERVICE:' + pkg).split())
> > > > -d.setVar('SYSTEMD_SERVICE:ESCAPED_' + pkg, paths_escaped)
> > > > +d.setVar('SYSTEMD_SERVICE_ESCAPED:' + pkg, paths_escaped)
> > >
> > > This is manually fixing the misconversion of _ESCAPED to :ESCAPED,
> > > right? If so then does it mean a bug in the automatic conversion
> > > script since overrides can't be uppercase?
> >
> > There are several bugs in the script, yes. The question is how far to go
> > in trying to address them and this wasn't a common issue.
>
> In case it isn't clear, this isn't as easy as you might first think. We need
> to convert SYSTEMD_SERVICE_${PN} which has uppercase characters in it. Can it
> be fixed? Probably, yes. Is it worth the effort/complexity? Maybe not.

I haven't read the script but doesn't it distinguish between things
following an _ which might be an override (and will never be all
uppercase) and the variable name which is being overridden (which may
be uppercase)?

Since the script will be reused many times for many private layers I'd
say making it as robust as possible is a worthy goal.

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



Re: [OE-core] [PATCH 3/3] meta: Manual override fixes

2021-07-28 Thread Andre McCurdy
On Wed, Jul 28, 2021 at 7:15 AM Richard Purdie
 wrote:
>
> The automated conversion of OE-Core to use the new override sytax isn't
> perfect. This patches some mis-converted lines and some lines which were 
> missed
> by the automation.
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/classes/insane.bbclass  |  2 +-
>  meta/classes/kernel-grub.bbclass |  8 
>  meta/classes/native.bbclass  |  2 +-
>  meta/classes/package.bbclass |  4 ++--
>  meta/classes/populate_sdk_ext.bbclass|  2 +-
>  meta/classes/qemuboot.bbclass|  2 ++
>  meta/classes/sanity.bbclass  |  2 +-
>  meta/classes/systemd.bbclass |  4 ++--
>  meta/classes/useradd.bbclass |  2 +-
>  meta/lib/oe/classextend.py   |  4 ++--
>  meta/lib/oe/recipeutils.py   | 16 
>  meta/lib/oeqa/selftest/cases/efibootpartition.py |  2 +-
>  meta/lib/oeqa/selftest/cases/incompatible_lic.py |  6 +++---
>  meta/lib/oeqa/selftest/cases/recipetool.py   |  4 ++--
>  meta/lib/oeqa/selftest/cases/wic.py  |  4 ++--
>  meta/recipes-core/dbus/dbus-test_1.12.20.bb  |  2 +-
>  .../volatile-binds/volatile-binds.bb |  2 +-
>  meta/recipes-devtools/gdb/gdb.inc|  2 +-
>  meta/recipes-graphics/mesa/mesa.inc  |  4 ++--
>  scripts/devtool  |  2 +-
>  20 files changed, 39 insertions(+), 37 deletions(-)
>
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index f9a35f2daac..ee858f84b7d 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -1306,7 +1306,7 @@ python () {
>  # Checking ${FILESEXTRAPATHS}
>  extrapaths = (d.getVar("FILESEXTRAPATHS") or "")
>  if '__default' not in extrapaths.split(":"):
> -msg = "FILESEXTRAPATHS-variable, must always use _prepend (or 
> _append)\n"
> +msg = "FILESEXTRAPATHS-variable, must always use :prepend (or 
> :append)\n"
>  msg += "type of assignment, and don't forget the colon.\n"
>  msg += "Please assign it with the format of:\n"
>  msg += "  FILESEXTRAPATHS:append := \":${THISDIR}/Your_Files_Path\" 
> or\n"
> diff --git a/meta/classes/kernel-grub.bbclass 
> b/meta/classes/kernel-grub.bbclass
> index 0bf8fda3e17..44b2015468a 100644
> --- a/meta/classes/kernel-grub.bbclass
> +++ b/meta/classes/kernel-grub.bbclass
> @@ -97,9 +97,9 @@ python __anonymous () {
>
>  for type in imagetypes.split():
>  typelower = type.lower()
> -preinst:append = preinst.replace('KERNEL_IMAGETYPE', type)
> -postinst:prepend = postinst.replace('KERNEL_IMAGETYPE', type)
> -d.setVar('pkg_preinst:kernel-image-' + typelower + '_append', 
> preinst:append)
> -d.setVar('pkg_postinst:kernel-image-' + typelower + '_prepend', 
> postinst:prepend)
> +preinst_append = preinst.replace('KERNEL_IMAGETYPE', type)
> +postinst_prepend = postinst.replace('KERNEL_IMAGETYPE', type)
> +d.setVar('pkg_preinst:kernel-image-' + typelower + ':append', 
> preinst_append)
> +d.setVar('pkg_postinst:kernel-image-' + typelower + ':prepend', 
> postinst_prepend)
>  }
>
> diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
> index 61becfb6d5e..76a599bc155 100644
> --- a/meta/classes/native.bbclass
> +++ b/meta/classes/native.bbclass
> @@ -133,7 +133,7 @@ python native_virtclass_handler () {
>
>  def map_dependencies(varname, d, suffix = "", selfref=True):
>  if suffix:
> -varname = varname + "_" + suffix
> +varname = varname + ":" + suffix
>  deps = d.getVar(varname)
>  if not deps:
>  return
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index 18f931ee947..a659a1ef5cc 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -1583,7 +1583,7 @@ fi
>  scriptlet = scriptlet_split[0] + "\nset -e\n" + 
> "\n".join(scriptlet_split[1:])
>  else:
>  scriptlet = "set -e\n" + "\n".join(scriptlet_split[0:])
> -d.setVar('%s_%s' % (scriptlet_name, pkg), scriptlet)
> +d.setVar('%s:%s' % (scriptlet_name, pkg), scriptlet)
>
>  def write_if_exists(f, pkg, var):
>  def encode(str):
> @@ -2310,7 +2310,7 @@ def gen_packagevar(d, pkgvars="PACKAGEVARS"):
>  ret.append(v)
>  for p in pkgs:
>  for v in vars:
> -ret.append(v + "_" + p)
> +ret.append(v + ":" + p)
>
>  # Ensure that changes to INCOMPATIBLE_LICENSE re-run do_package for
>  # affected recipes.
> diff --git a/meta/classes/populate_sdk_ext.bbclass 
> b/meta/classes/populate_sdk_ext.bbclass
> index f67849708cd..10f3265e91b 100644
> --- a/meta/classes/populate_sdk_ext.bbclass
> +++ 

Re: [OE-core][dunfell][PATCH v2 1/3] cmake-native: enabled zstd support

2021-07-27 Thread Andre McCurdy
On Tue, Jul 27, 2021 at 12:24 AM Richard Purdie
 wrote:
>
> On Mon, 2021-07-26 at 14:40 -1000, Steve Sakoman wrote:
> > On Mon, Jul 26, 2021 at 12:27 PM Ruslan Babayev (fib)  
> > wrote:
> > >
> > > Hi Steve,
> > >
> > > Thanks for reviewing the patches. I understand the problem of merging this
> > > patch as is.
> > > But Dunfell currently has a host contamination issue on systems with zstd
> > > installed as part of base OS resulting in broken cmake-native recipe. Can
> > > you help bring this up to the attention of the steering committee?
> >
> > Perhaps Richard can comment on this.  You are asking for a feature
> > change to dunfell that involves modifications in both
> > openembedded-core and meta-openembedded. So both technical steering
> > committees would need to agree that this is appropriate.
>
> We don't have to go straight to the TSC, the layer maintainers can try and
> agree a plan first.
>
> I've added Armin as meta-openembedded maintainer for dunfell.
>
> Context: cmake-native suffers host contamination on dunfell due to zstd being
> detected on the host. The upstream cmake community say they don't support
> configuring it without it.
>
> Do we agree we should move zstd from meta-oe to oe-core in dunfell to fix
> this? Should we patch cmake in dunfell to try and use it's own copy of zstd
> internally? The latter is more risky in that we've not tried that and multiple
> configures can be 'fun' in builds. Moving the recipe has a different kind of
> pain.

There's no need to move the recipe, just adding to oe-core should be enough.

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



Re: [OE-core] [PATCH v2] rootfs: remove ldconfig auxiliary cache where appropriate

2021-07-23 Thread Andre McCurdy
On Fri, Jul 23, 2021 at 2:22 AM Damian Wrobel
 wrote:
>
> Removes the /var/cache/ldconfig auxiliary cache directory from
> the rootfs when:
>  - read-only-rootfs is in DISTRO_FEATURES,
>  - ldconfig is not in DISTRO_FEATURES.

Comments say DISTRO_FEATURES but code is checking IMAGE_FEATURES in both cases.

ldconfig is a distro feature and read-only-rootfs is an image feature,
so both the comments and code seem to be wrong...

> In both cases the /var/cache/ldconfig/aux-cache is useless.
>
> Signed-off-by: Damian Wrobel 
> ---
>  meta/lib/oe/rootfs.py | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
> index ad9fd77c8b..8e63ebac9b 100644
> --- a/meta/lib/oe/rootfs.py
> +++ b/meta/lib/oe/rootfs.py
> @@ -302,6 +302,16 @@ class Rootfs(object, metaclass=ABCMeta):
>  self._exec_shell_cmd(['ldconfig', '-r', self.image_rootfs, '-c',
>'new', '-v', '-X'])
>
> +image_rorfs = bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs",
> +True, False, self.d)
> +ldconfig_in_features = bb.utils.contains("IMAGE_FEATURES", 
> "ldconfig",
> + True, False, self.d)
> +if image_rorfs or not ldconfig_in_features:
> +ldconfig_cache_dir = os.path.join(self.image_rootfs, 
> "var/cache/ldconfig")
> +if os.path.exists(ldconfig_cache_dir):
> +bb.note("Removing ldconfig auxiliary cache...")
> +shutil.rmtree(ldconfig_cache_dir)
> +
>  def _check_for_kernel_modules(self, modules_dir):
>  for root, dirs, files in os.walk(modules_dir, topdown=True):
>  for name in files:
> --
> 2.31.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154119): 
https://lists.openembedded.org/g/openembedded-core/message/154119
Mute This Topic: https://lists.openembedded.org/mt/84397515/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] rootfs: remove ldconfig auxiliary cache where appropriate

2021-07-23 Thread Andre McCurdy
On Fri, Jul 23, 2021 at 2:16 AM Damian Wrobel
 wrote:
>
>   On Thu, 22 Jul 2021 21:00:15 +0200 Andre McCurdy  
> wrote 
>  > On Thu, Jul 22, 2021 at 2:48 AM Damian Wrobel
>  >  wrote:
>  > >
>  > > Removes the /var/cache/ldconfig auxiliary cache directory from
>  > > the rootfs when:
>  > >  - read-only-rootfs is in DISTRO_FEATURES,
>  > >  - ldconfig is not in DISTRO_FEATURES.
>  > >
>  > > In both cases the /var/cache/ldconfig/aux-cache is useless.
>  >
>  > Should there be a test for package management being supported in the
>  > image too? A read-only rootfs is one case where it's not possible to
>  > install ldconfig support at run time but a writeable rootfs without
>  > package management support would seem to be another?
>
> It seems to be perfectly fine to use the ldconfig without having any package 
> management system.

Of course. But if ldconfig support is disabled at build time (ie the
ldconfig distro feature is disabled) and there is no package
management support (so ldconfig can not be installed at run time) then
is there any need for /var/cache/ldconfig/aux-cache ?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154118): 
https://lists.openembedded.org/g/openembedded-core/message/154118
Mute This Topic: https://lists.openembedded.org/mt/84375612/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] rootfs: remove ldconfig auxiliary cache where appropriate

2021-07-22 Thread Andre McCurdy
On Thu, Jul 22, 2021 at 2:48 AM Damian Wrobel
 wrote:
>
> Removes the /var/cache/ldconfig auxiliary cache directory from
> the rootfs when:
>  - read-only-rootfs is in DISTRO_FEATURES,
>  - ldconfig is not in DISTRO_FEATURES.
>
> In both cases the /var/cache/ldconfig/aux-cache is useless.

Should there be a test for package management being supported in the
image too? A read-only rootfs is one case where it's not possible to
install ldconfig support at run time but a writeable rootfs without
package management support would seem to be another?

> Signed-off-by: Damian Wrobel 
> ---
>  meta/lib/oe/rootfs.py | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
> index ad9fd77c8b..80673fab3f 100644
> --- a/meta/lib/oe/rootfs.py
> +++ b/meta/lib/oe/rootfs.py
> @@ -302,6 +302,15 @@ class Rootfs(object, metaclass=ABCMeta):
>  self._exec_shell_cmd(['ldconfig', '-r', self.image_rootfs, '-c',
>'new', '-v', '-X'])
>
> +image_rorfs = bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs",
> +True, False, self.d)
> +ldconfig_in_features = bb.utils.contains("IMAGE_FEATURES", 
> "ldconfig",
> + True, False, self.d)
> +if image_rorfs or not ldconfig_in_features:
> +ldconfig_cache_dir = os.path.join(self.image_rootfs, 
> "var/cache/ldconfig")
> +bb.note("Removing ldconfig auxiliary cache...")
> +shutil.rmtree(ldconfig_cache_dir)
> +
>  def _check_for_kernel_modules(self, modules_dir):
>  for root, dirs, files in os.walk(modules_dir, topdown=True):
>  for name in files:
> --
> 2.31.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154065): 
https://lists.openembedded.org/g/openembedded-core/message/154065
Mute This Topic: https://lists.openembedded.org/mt/84375612/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] how to configure an image with *full* debugging info in the libs and binaries?

2021-07-20 Thread Andre McCurdy
On Mon, Jul 19, 2021 at 5:06 PM Ross Burton  wrote:
> On Fri, 16 Jul 2021 at 20:10, Robert P. J. Day  wrote:
> >   colleague just asked me what it would take to generate an image
> > where the executables and libraries contain all the gdb-related
> > debugging info in the same files (that is, not broken out in the
> > .debug directories).
> >
> >   i pointed out that this would increase the size of the installable
> > target image substantially but, apparently, that is of no concern.
>
> This is where I have to ask "why?".  All known debugging tools can
> handle split-out debuginfo, and getting them all installed into an
> image is as simple as IMAGE_FEATURES += dbg-pkgs, as Khem says.

Why is an interesting side discussion. Getting back to the original
question though, either OE officially supports creating unstripped
binaries or it doesn't. The documentation should perhaps be updated to
make that clear (and if there's legacy support for creating unstripped
binaries still lurking in the code but we don't want anyone to use it,
then maybe it should be removed...).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154009): 
https://lists.openembedded.org/g/openembedded-core/message/154009
Mute This Topic: https://lists.openembedded.org/mt/84256404/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] pypi: set SRC_URI with =, not with +=

2021-06-24 Thread Andre McCurdy
On Wed, Jun 23, 2021 at 3:18 AM Alexander Kanavin
 wrote:
>
> Frankly guys, I think maybe we should just break stuff in this case, and have 
> it fixed up properly, then try to guess what workaround might work.
>
> From that perspective the original patch is the most clear.

The typical ordering of variables etc in recipes is to put SRC_URI
before inherit.

>From the perspective of trying to get recipes to stick to a standard
ordering of variables etc, _prepend seems to be the best solution.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153253): 
https://lists.openembedded.org/g/openembedded-core/message/153253
Mute This Topic: https://lists.openembedded.org/mt/83721889/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] should the same recipe have two different WORKDIRs?

2021-06-16 Thread Andre McCurdy
On Wed, Jun 16, 2021 at 9:30 AM Robert P. J. Day  wrote:
>   perhaps i've just never noticed before, but a colleague asked me to
> debug some strangeness with his WRLinux build, and what i noticed was
> that the recipe that generated a package with a single (aarch64)
> executable created WORKDIRs under both directories:
>
>   * cortexa53...
>   * acme-coyote [actual target board]
>
> this surprises me ... i thought that, based on the attributes of any
> recipe, it would have only one WORKDIR in the appropriate place. what
> does the above mean? i'm not sure what to make of it.

Have you built the recipe for two different machines in the same build
directory?

If you completely remove tmp and then build again for a single machine
you should see only one WORKDIR created (which could be under either
the generic cortexa53 or the machine specific acme-coyote depending on
whether the recipe sets PACKAGE_ARCH or applies any patches or sets
config option etc using a machine specific override).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153029): 
https://lists.openembedded.org/g/openembedded-core/message/153029
Mute This Topic: https://lists.openembedded.org/mt/83584601/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] ffmpeg: link in libatomic on 32-bit mips

2021-06-15 Thread Andre McCurdy
On Mon, Jun 14, 2021 at 8:54 PM kai  wrote:
>
> From: Kai Kang 
>
> It needs some functions from libatomic on 32-bit mips too:
>
> | libavformat/libavformat.so: undefined reference to `__atomic_fetch_sub_8'
>
> Signed-off-by: Kai Kang 
> ---
>  meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.bb 
> b/meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.bb
> index 3ed009bbb7..f3097f8ebf 100644
> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.bb
> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.bb
> @@ -130,6 +130,7 @@ EXTRA_OECONF += "${@bb.utils.contains('TUNE_FEATURES', 
> 'mips32r6', '--disable-mi
>  EXTRA_OECONF_append_mips = " --extra-libs=-latomic --disable-mips32r5 
> --disable-mipsdsp --disable-mipsdspr2 \
>   --disable-loongson2 --disable-loongson3 
> --disable-mmi --disable-msa --disable-msa2"
>  EXTRA_OECONF_append_riscv32 = " --extra-libs=-latomic"
> +EXTRA_OECONF_append_powerpc = " --extra-libs=-latomic"

Subject mentions mips, not powerpc.

>  # gold crashes on x86, another solution is to --disable-asm but thats more 
> hacky
>  # ld.gold: internal error in relocate_section, at ../../gold/i386.cc:3684
> --
> 2.17.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152953): 
https://lists.openembedded.org/g/openembedded-core/message/152953
Mute This Topic: https://lists.openembedded.org/mt/83548820/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] [V2][PATCH] libjpeg-turbo: fix do_compile error on armv5

2021-06-10 Thread Andre McCurdy
On Thu, Jun 10, 2021 at 2:42 AM Changqing Li  wrote:
> On 6/10/21 1:29 AM, Andre McCurdy wrote:
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> >
> > On Wed, Jun 9, 2021 at 12:32 AM Changqing Li  
> > wrote:
> >> From: Changqing Li 
> >>
> >> fix below error:
> >> /include/arm_neon.h:31:2: error: #error "NEON intrinsics not available 
> >> with the soft-float ABI. Please use -mfloat-abi=softfp or -mfloat-abi=hard"
> >> 31 | #error "NEON intrinsics not available with the soft-float ABI. Please 
> >> use -mfloat-abi=softfp or -mfloat-abi=hard"
> >>
> >> Neon is not supported by armv5, disable the simd extension build.
> > Drop this comment. Neon may be missing from other ISA levels too (i.e.
> > this fix is not specific to armv5).
> Get it. Thanks.
> >
> >> Signed-off-by: Changqing Li 
> >> ---
> >>   meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb 
> >> b/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb
> >> index 7f91cc02ac..da21971113 100644
> >> --- a/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb
> >> +++ b/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb
> >> @@ -40,6 +40,8 @@ EXTRA_OECMAKE_append_class-target = " 
> >> ${@bb.utils.contains("TUNE_FEATURES", "mx3
> >>   # Work around missing non-floating point ABI support in MIPS
> >>   EXTRA_OECMAKE_append_class-target = " 
> >> ${@bb.utils.contains("MIPSPKGSFX_FPU", "-nf", "-DWITH_SIMD=False", "", d)}"
> >>
> >> +EXTRA_OECMAKE_append_class-target = " ${@ ('') if 
> >> (d.getVar('TUNE_CCARGS_MFPU') != '') else '-DWITH_SIMD=False'}"
> > Shouldn't this be checking for neon in TUNE_FEATURES rather than
> > TUNE_CCARGS_MFPU?
> Refer feature-arm-vfp.inc:
>
> TUNE_CCARGS_MFLOAT = "${@ bb.utils.contains('TUNE_FEATURES',
> 'callconvention-hard', 'hard', 'softfp', d) if
> (d.getVar('TUNE_CCARGS_MFPU') != '') else '' }"
>
> TUNE_CCARGS   .= "${@ ' -mfloat-abi=${TUNE_CCARGS_MFLOAT}' if
> (d.getVar('TUNE_CCARGS_MFLOAT') != '') else ''}"
>
>
> There are condition that neon is not in TUNE_FEATURES, but vfp is in it.
> so TUNE_CCARGS may append -mfloat-abi=softfp,  then
>
> simd module here can be compiled  sucessfully.

The SIMD code can only be used on targets which support neon. There
may be other cases where the code can be compiled but if it can never
be used at run time it's not very useful.

> > It should also probably be conditional on the _arm
> > over-ride since neon will be missing from
> > TUNE_CCARGS_MFPU/TUNE_FEATURES for other architectures.Since big
> > endian ARM doesn't use the _arm over-ride you will also need a
> > duplicate line with the same logic with the _armeb override too. See
> > the lines below which do the equivalent for _powerpc / _powerpc64 as a
> > reference.
> ok. thanks.
>
> >
> >>   # Provide a workaround if Altivec unit is not present in PPC
> >>   EXTRA_OECMAKE_append_class-target_powerpc = " 
> >> ${@bb.utils.contains("TUNE_FEATURES", "altivec", "", "-DWITH_SIMD=False", 
> >> d)}"
> >>   EXTRA_OECMAKE_append_class-target_powerpc64 = " 
> >> ${@bb.utils.contains("TUNE_FEATURES", "altivec", "", "-DWITH_SIMD=False", 
> >> d)}"
> >> --
> >> 2.17.1
> >>
> >>
> >> 
> >>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152832): 
https://lists.openembedded.org/g/openembedded-core/message/152832
Mute This Topic: https://lists.openembedded.org/mt/83415559/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] [V2][PATCH] libjpeg-turbo: fix do_compile error on armv5

2021-06-09 Thread Andre McCurdy
On Wed, Jun 9, 2021 at 12:32 AM Changqing Li  wrote:
>
> From: Changqing Li 
>
> fix below error:
> /include/arm_neon.h:31:2: error: #error "NEON intrinsics not available with 
> the soft-float ABI. Please use -mfloat-abi=softfp or -mfloat-abi=hard"
> 31 | #error "NEON intrinsics not available with the soft-float ABI. Please 
> use -mfloat-abi=softfp or -mfloat-abi=hard"
>
> Neon is not supported by armv5, disable the simd extension build.

Drop this comment. Neon may be missing from other ISA levels too (i.e.
this fix is not specific to armv5).

> Signed-off-by: Changqing Li 
> ---
>  meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb 
> b/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb
> index 7f91cc02ac..da21971113 100644
> --- a/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb
> +++ b/meta/recipes-graphics/jpeg/libjpeg-turbo_2.1.0.bb
> @@ -40,6 +40,8 @@ EXTRA_OECMAKE_append_class-target = " 
> ${@bb.utils.contains("TUNE_FEATURES", "mx3
>  # Work around missing non-floating point ABI support in MIPS
>  EXTRA_OECMAKE_append_class-target = " ${@bb.utils.contains("MIPSPKGSFX_FPU", 
> "-nf", "-DWITH_SIMD=False", "", d)}"
>
> +EXTRA_OECMAKE_append_class-target = " ${@ ('') if 
> (d.getVar('TUNE_CCARGS_MFPU') != '') else '-DWITH_SIMD=False'}"

Shouldn't this be checking for neon in TUNE_FEATURES rather than
TUNE_CCARGS_MFPU? It should also probably be conditional on the _arm
over-ride since neon will be missing from
TUNE_CCARGS_MFPU/TUNE_FEATURES for other architectures. Since big
endian ARM doesn't use the _arm over-ride you will also need a
duplicate line with the same logic with the _armeb override too. See
the lines below which do the equivalent for _powerpc / _powerpc64 as a
reference.

>  # Provide a workaround if Altivec unit is not present in PPC
>  EXTRA_OECMAKE_append_class-target_powerpc = " 
> ${@bb.utils.contains("TUNE_FEATURES", "altivec", "", "-DWITH_SIMD=False", d)}"
>  EXTRA_OECMAKE_append_class-target_powerpc64 = " 
> ${@bb.utils.contains("TUNE_FEATURES", "altivec", "", "-DWITH_SIMD=False", d)}"
> --
> 2.17.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152810): 
https://lists.openembedded.org/g/openembedded-core/message/152810
Mute This Topic: https://lists.openembedded.org/mt/83415559/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] want to clarify proper approach to shared lib (.so) installation

2021-06-04 Thread Andre McCurdy
On Thu, Jun 3, 2021 at 7:26 AM Robert P. J. Day  wrote:
>
> On Thu, 3 Jun 2021, Andrea Adami wrote:
>
> > On Thu, Jun 3, 2021 at 4:01 PM Robert P. J. Day  
> > wrote:
> > >
> > >
> > >   sort of a 2-part soliloquy. in current YP code base i've inherited,
> > > most of the internal (local directory SRC_URI-based) recipes inherit a
> > > proprietary class that, among doing other internal, proprietary
> > > things, totally redefines PACKAGES as:
> > >
> > >   PACKAGES = "${PN} ... ${PN}-dev ..."
> > >
> > > i had never really noticed that before, but it's pretty obvious that
> > > that's not a great idea, as it allows what i call the recipe "base"
> > > package (${PN}) to gather up everything that matches its standard
> > > wildcard pattern before moving on, in effect "stealing" content from
> > > subsequent packages they would normally get if the base package was at
> > > the end, not the beginning.
> > >
> > >   somehow, this has worked all this time, but it's clear(?) that what
> > > would be the "normal" contents of the various packages isn't going to
> > > be what one would expect; in particular, the base package is going to
> > > be what i call "overpackaged", with lots of stuff it doesn't really
> > > need so i'm guessing what's going into the image is more than is
> > > really necessary. somehow, though, it's worked all this time until
> > > recently, when i noticed this quirk was causing some Q/A issues, so i
> > > took a deep breath, commented out that line from the class file to use
> > > the default packaging approach and re-tried the build, which is when
> > > all hell broke loose.
> > >
> > >   it turns out that these internal recipes use local Makefile-based
> > > source directories, which build, then install their generated
> > > artifacts in a temporary (non-YP) staging area per recipe, *then*
> > > manually (little by little) install stuff in ${D} via a general
> > > do_install() routine, at which point the regular packaging and
> > > subsequent steps kick in, but it's what now gets copied into ${D} that
> > > is causing grief.
> > >
> > >   apparently, many of these recipes generate a shared library, and i'm
> > > well aware that the *normal* packaging involving a shared library is
> > > like this example from libidn2 (snipped for brevity to show only
> > > shared lib stuff):
> > >
> > >  libidn2/
> > >   usr/
> > >lib/
> > > libidn2.so.0 -> libidn2.so.0.3.7
> > > libidn2.so.0.3.7[actual library file]
> > >
> > >  libidn2-dev/
> > >   usr/
> > >lib/
> > > libidn2.so -> libidn2.so.0.3.7
> > >
> > > so the *normal* packaging for a shared lib is that the lib itself and
> > > a symlink to it go into the base package, while another symlink goes
> > > into the "-dev" package. i'd never really paid that much attention to
> > > that until i reset that PACKAGES variable, as all of these internal
> > > recipes end up installing into ${D} nothing but the shared lib file
> > > itself under /usr/lib, and why this has worked all this time is a
> > > mystery, but having made this change is generating all sorts of Q/A
> > > diagnostics as this is what ends up in ${D} using a "fubar" recipe
> > > example given the manual installation being done using normal
> > > packaging:
> > >
> > >  fubar/
> > >   usr/
> > >bin/
> > > ... snip ...
> > >no lib/ directory
> > >
> > >  fubar-dev/
> > >   usr/
> > >lib/
> > > libfnvcma.so[actual shared lib]
> > >
> > > unsurprisingly, there are QA issues with the above:
> > >
> > > ERROR: fubar-1.0-r0 do_package_qa: QA Issue: -dev package contains 
> > > non-symlink .so: fubar-dev
> > > path .../packages-split/fubar-dev/usr/lib/libfnvcma.so'[dev-elf]
> > > ERROR: fubar-1.0-r0 do_package_qa: QA Issue: fubar rdepends on fubar-dev 
> > > [dev-deps]
> > >
> > >   *sigh*.
> > >
> > >   in short, because these internal recipes generate only the single
> > > shared lib file itself and that's all that's copied into ${D}, the
> > > regular Q/A tests will naturally barf, and i could use INSANE_SKIP all
> > > over the place to get around this, but it seems to me that the proper
> > > approach is to tell the developers that they need to start generating
> > > the appropriate symlinks for all of their recipes so packaging is done
> > > properly.
> > >
> > >   i'm just about to check if there is a switch or class i can invoke
> > > that will "fix" this issue (as in, set up the shared libs in ${D}
> > > properly), but apart from that, am i correct in thinking that the
> > > developers need to do this correctly from the beginning?
> > >
> > > rday
> > >
> > >
> > >
> >
> > Hi,
> > in the latter example you are packaging an unversioned shlib:
> >
> > libfnvcma.so[actual shared lib]
> >
> > In this case you might play with
> >  SOLIBS = ".so"
> >  FILES_SOLIBSDEV = ""
> >
> > Please have a look at
> > https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
>
>   excellent, i was sure 

Re: [OE-core] master/main branch renaming and bitbake

2021-05-19 Thread Andre McCurdy
On Thu, May 13, 2021 at 3:48 PM Richard Purdie
 wrote:
>
> On Thu, 2021-05-13 at 17:33 -0400, colin walters wrote:
> >
> > On Thu, May 13, 2021, at 4:08 PM, Richard Purdie wrote:
> > >
> > > The advice to anyone hitting this issue is to add in the correct branch
> > > to the SRC_URI. It is simple and easy to do, can be in bbappends
> > > or even changed via anonymous python and similar if necessary. We've 
> > > already
> > > found the issue with several core recipes, we simply updated them and most
> > > users didn't notice. I would even likely take that kind of change into 
> > > older
> > > otherwise unmaintained branches and I think I did so in at least one case 
> > > in
> > > the past.
> >
> > What I am uncertain about is: how quickly does that translate into us being
> > able to remove the old branch?
>
> My personal opinion is see the patches updating the SRC_URIs make the branches
> given we know about this one and then do it.
>
> > We're not the first project to do this and we won't be the last, so having a
> > solution here will be good.
>
> I'm suggesting people update the recipes.
>
> > Hmm actually I notice systemd upstream did the rename a while ago and 
> > they're
> > not carrying a `master` branch.  What's the difference between systemd and 
> > ostree here?
> >
> > Is it the use of `SRCREV`?  Or no, in the systemd case is it because it's 
> > set to a tag?
> > https://github.com/openembedded/openembedded-core/blob/2621dbbc1181808f18ca4ae79408d0d5b557670f/meta/recipes-core/systemd/systemd.inc#L18
> > ostree is also using tags, is the recipe just broken in not using tags?
>
> No:
>
> SRCBRANCH = "v247-stable"
> SRC_URI = 
> "git://github.com/systemd/systemd-stable.git;protocol=git;branch=${SRCBRANCH}
>
> i.e. there is a specific branch specified.
>
> > > I appreciate the tooling could do all kinds of magic things. I have a 
> > > strong
> > > preference for not adding magic into it, or over complicating it, it is 
> > > already
> > > horrendously complicated and a nightmare to test. I appreciate nobody 
> > > believes
> > > me, I only do my best to maintain it. The code is here for anyone 
> > > interested:
> > >
> > > http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/git.py
> >
> > Yeah, understood.
> >
> > > I'd also note you can add ;nobranch=1 to the urls or ;usehead=1. Those do
> > > have side effects, I will not recommend them, or accept them for general 
> > > use
> > > in layers I maintain, they're considered developer options. I was reminded
> > > recently that we have seen bugs the branch parameter has caught where a
> > > revision was not where we thought it was so these do catch real world 
> > > issues.
> >
> > Well I hope the result of this discussion is a recommended best practice at 
> > least.
> > If recommending using a tag works, that seems good to me.
>
> People should add/update the branch in SRC_URI.

Could we perhaps have an "official" recommendation on that somewhere
which users etc could be pointed to?

I've just had a discussion along the lines of "but ;nobranch=1 works
and will be more robust than setting ;branch=main if upstream changes
their mind again". From a user's point of view it's not clear at all
that setting branch is the better solution or why.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152050): 
https://lists.openembedded.org/g/openembedded-core/message/152050
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] how to create debugfs while ruthlessly stripping image contents?

2021-05-18 Thread Andre McCurdy
On Tue, May 18, 2021 at 10:00 AM Robert P. J. Day  wrote:
>   muh colleague just presented me with the following ... until
> recently, build was properly producing bootable image while
> simultaneously creating companion debugfs. so far, so good.
>
>   then enough packages were added so that image didn't fit in target
> eMMC, so decision was made to strip bins and libs in ${D} image/
> directory via sneaking the following into do_install_append():
>
>   ${STRIP} -p --strip-unneeded ${D}${bindir}/*
>   ${STRIP} -p --strip-unneeded ${D}${libdir}/*

Did that actually help with the image size?

> as soon as this kicked in, the complaint was that numerous objects
> were now missing from the debugfs, and i *suspect* (working to
> confirm) that, having stripped all those binaries and libraries before
> the packaging step kicks in, a lot of stuff that would have ended up
> in the debugfs is now bypassed since it lacks the appropriate
> debugging info anymore.

Yes, if you remove debug symbols before packaging then they won't be
available to put in the -dbg packages.

>   i'm looking at the various variables to see what would support:
>
>   1) stripping image-bound bins and libs, while
>   2) retaining debugging info to build debugfs

Isn't that what happens by default?

> a stack overflow page suggests something like:
>
>   INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
>   INHIBIT_PACKAGE_STRIP = "1"
>   DEBUG_BUILD = "1"
>   EXTRA_IMAGE_FEATURES_append = " dbg-pkgs"

This came up on the list a few months ago. Enabling every possible
option somehow related to debug as advised by stack overflow probably
isn't the best approach. You need to decide if you want to have
unstripped binaries in the image (in which case there's no need to
install separate -dbg packages in the image too), if you want stripped
binaries and -dbg packages in the image (in which case there's no
point trying to disable splitting of debug symbols during packaging)
or if you want debug symbols in a separate image / tar file (in which
case you don't need to change packaging or the contents of the main
image at all).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152037): 
https://lists.openembedded.org/g/openembedded-core/message/152037
Mute This Topic: https://lists.openembedded.org/mt/82916837/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] mklibs-native: Fix build with gcc 11

2021-05-17 Thread Andre McCurdy
On Mon, May 17, 2021 at 10:05 AM Jacob Kroon  wrote:
>
> In gcc 11 the default mode for C++ is now -std=gnu++17 instead of 
> -std=gnu++14,
> in which support for dynamic exception specifications has been removed.

As much as I'd like to see mklibs fully supported in OE, at some point
maybe we should just admit that it doesn't work and there's not enough
collective motivation to fix it.

For mklibs to work, the build process should generate a PIC .a archive
for every .so shared library (ie static libs need to be built and
somehow forced to contain PIC object code - which may mean patching
Makefiles etc) and then the PIC .a files need to be available
alongside the .so libs when mklibs runs. We don't have any support for
doing that, so why keep pretending to support mklibs?

> See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html
>
> Signed-off-by: Jacob Kroon 
> ---
>  .../no-dynamic-exception-specifications.patch | 420 ++
>  .../mklibs/mklibs-native_0.1.44.bb|   1 +
>  2 files changed, 421 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/mklibs/files/no-dynamic-exception-specifications.patch
>
> diff --git 
> a/meta/recipes-devtools/mklibs/files/no-dynamic-exception-specifications.patch
>  
> b/meta/recipes-devtools/mklibs/files/no-dynamic-exception-specifications.patch
> new file mode 100644
> index 00..5989a67c4f
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/mklibs/files/no-dynamic-exception-specifications.patch
> @@ -0,0 +1,420 @@
> +In gcc 11 the default mode for C++ is now -std=gnu++17 instead of 
> -std=gnu++14,
> +in which support for dynamic exception specifications has been removed.
> +
> +See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Jacob Kroon 
> +
> +Index: mklibs-0.1.44/src/mklibs-readelf/elf.cpp
> +===
> +--- mklibs-0.1.44.orig/src/mklibs-readelf/elf.cpp
>  mklibs-0.1.44/src/mklibs-readelf/elf.cpp
> +@@ -36,7 +36,7 @@ file::~file () throw ()
> + delete *it;
> + }
> +
> +-file *file::open (const char *filename) throw (std::bad_alloc, 
> std::runtime_error)
> ++file *file::open (const char *filename)
> + {
> +   struct stat buf;
> +   int fd;
> +@@ -72,7 +72,7 @@ file *file::open (const char *filename)
> + }
> +
> + template
> +-file *file::open_class(uint8_t *mem, size_t len) throw (std::bad_alloc, 
> std::runtime_error)
> ++file *file::open_class(uint8_t *mem, size_t len)
> + {
> +   switch (mem[EI_DATA])
> +   {
> +@@ -86,7 +86,7 @@ file *file::open_class(uint8_t *mem, siz
> + }
> +
> + template 
> +-file_data<_class, _data>::file_data(uint8_t *mem, size_t len) throw 
> (std::bad_alloc, std::runtime_error)
> ++file_data<_class, _data>::file_data(uint8_t *mem, size_t len)
> + : file(mem, len)
> + {
> +   if (mem[EI_CLASS] != _class::id)
> +@@ -190,7 +190,7 @@ section_data<_class, _data>::section_dat
> + }
> +
> + template 
> +-void section_data<_class, _data>::update(const file ) throw 
> (std::bad_alloc)
> ++void section_data<_class, _data>::update(const file )
> + {
> +   const section_type  =
> + dynamic_cast 
> &>(file.get_section(file.get_shstrndx()));
> +@@ -204,7 +204,7 @@ section_type::~sec
> + }
> +
> + template 
> +-section_real<_class, _data, section_type_DYNAMIC>::section_real(Shdr 
> *header, uint8_t *mem) throw (std::bad_alloc)
> ++section_real<_class, _data, section_type_DYNAMIC>::section_real(Shdr 
> *header, uint8_t *mem)
> + : section_data<_class, _data>(header, mem)
> + {
> +   if (this->type != SHT_DYNAMIC)
> +@@ -221,7 +221,7 @@ section_real<_class, _data, section_type
> + }
> +
> + template 
> +-void section_real<_class, _data, section_type_DYNAMIC>::update(const file 
> ) throw (std::bad_alloc)
> ++void section_real<_class, _data, section_type_DYNAMIC>::update(const file 
> )
> + {
> +   section_data<_class, _data>::update(file);
> +
> +@@ -243,7 +243,7 @@ section_type::~sect
> + }
> +
> + template 
> +-section_real<_class, _data, section_type_DYNSYM>::section_real(Shdr 
> *header, uint8_t *mem) throw (std::bad_alloc)
> ++section_real<_class, _data, section_type_DYNSYM>::section_real(Shdr 
> *header, uint8_t *mem)
> + : section_data<_class, _data>(header, mem)
> + {
> +   if (this->type != SHT_DYNSYM)
> +@@ -260,7 +260,7 @@ section_real<_class, _data, section_type
> + }
> +
> + template 
> +-void section_real<_class, _data, section_type_DYNSYM>::update(const file 
> ) throw (std::bad_alloc)
> ++void section_real<_class, _data, section_type_DYNSYM>::update(const file 
> )
> + {
> +   section_data<_class, _data>::update (file);
> +
> +@@ -285,7 +285,7 @@ const version_definition *section_type + }
> +
> + template 
> +-section_real<_class, _data, section_type_GNU_VERDEF>::section_real(Shdr 
> *header, uint8_t *mem) throw (std::bad_alloc)
> ++section_real<_class, _data, section_type_GNU_VERDEF>::section_real(Shdr 
> *header, uint8_t *mem)
> + : 

Re: [OE-core] is there an easy to prevent *creation* of some recipe's packages?

2021-05-17 Thread Andre McCurdy
On Fri, May 14, 2021 at 5:39 AM Konrad Weihmann  wrote:
>
> On 14.05.21 13:52, Robert P. J. Day wrote:
> > On Fri, 14 May 2021, Konrad Weihmann wrote:
> >
> >> On 14.05.21 13:16, Robert P. J. Day wrote:
> >>>
> >>> pretty sure i know the answer to this one, but was asked the
> >>> other day and wanted to make sure. in order to speed up the normal
> >>> OE build, someone suggested bypassing the creation of packages
> >>> that weren't going to be relevant, such as -dev, -doc and so on --
> >>> the idea was that that could make a significant difference in
> >>> build time.
> >>
> >> I pretty much doubt it will speed up anything. If for instance the
> >> -dev package will be removed from PACKAGES it is very likely that
> >> the files of that package will end up in the base package ${PN},
> >> which results in larger target packages that need to be installed
> >> (and potentially further RDEPENDS)
> >>
> >> Furthermore this will break DEPENDS for recipes that do rely on the
> >> -dev package - so chances are high that this will break (or
> >> magically change) something further down the line.
> >>
> >> One thing that you can do to speed up the build process in terms of
> >> packaging time is to delete any **really** not needed files in a
> >> do_install_append, if no proper configuration option (cmake flag,
> >> make flag, PACKAGECONFIG) does exist which prevents the creation of
> >> these files in the first place.
> >>
> >> I would recommend not to mess with the packaging defaults for
> >> reasons such as speeding things up - as this is IMHO addressing the
> >> issue at the wrong end - just make sure the files in /image
> >> won't get created
> >
> >that's the general idea i was trying to get across (so let's confirm
> > that i was speaking accurately). i suggested that the majority of time
> > spent in processing a recipe was doing all the fetching and unpacking
> > and patching and (mostly) compiling, the end result of which was to
> > populate that recipe's WORKDIR/image directory, at which time the
> > packaging step took over. so unless one wanted to dangerously mangle
> > the package definitions, if it ended up in ${D}, it was going to get
> > packaged, correct?
>
> yes... *but* what the packaging does it to loop over PACKAGES and for
> each item pick up the corresponding FILES_ var and "move" (I
> think it's actually a copy, but that's just details) all matching files
> from image to packages-split.
> If files ending up in image that don't match *any* of the
> FILES-glob-pattern one would get a QA error.
>
> >
> >so unless one wanted to go back and mess with the recipe's build
> > configuration to, perhaps, not generate some artifacts, those packages
> > were going to be built, whether they were subsequently installed or
> > not. so short of mangling each recipe file to change its
> > configuration, just leave it alone as the payoff just isn't worth it.
> >
> >sound about right?
>
> yes - the results of trimming down the input to /image will much more
> have a positive impact.
>
> AFAIK packaging speed is directly linked to the number of files in
> /image (worst example I've seen is a ruby package containing 250k+
> files, which takes round about 20min to package on my machine) -
> concluding from that, reduction of the number of files in /image is will
> do the trick

This thread seems to have covered the main point already (if you want
to save time by not packaging unwanted files then don't install the
files in the first place).

It's perhaps worth noting one very common case where files are
installed and packaged unnecessarily and that's having the ptest
distro feature enabled even though you don't intend to install any
ptest packages. For most users ptest should be something you enable
selectively when you want to prove the functionality of recipes in
oe-core (e.g. after upgrading to a new OE release or when bringing up
a new machine) and then disable again afterwards.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151989): 
https://lists.openembedded.org/g/openembedded-core/message/151989
Mute This Topic: https://lists.openembedded.org/mt/82821703/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] couple questions about creating companion debug filesystem

2021-05-13 Thread Andre McCurdy
On Thu, May 13, 2021 at 3:36 AM Robert P. J. Day  wrote:
>
>   couple colleagues asked me about the details of how the debug
> filesystem is created, and since i wasn't entirely clear on the
> mechanics of it myself, i thought i'd dig into it, so a couple
> preliminary questions to make sure i'm on the right track.
>
>   trivially, if you want that companion debugfs, you need only:
>
>   IMAGE_GEN_DEBUGFS = '1'
>
> at which point what kicks in is the current value of
> IMAGE_FSTYPES_DEBUGFS to determine what forms of the debugfs you want.
> by default, that's conditionally set to "tar.gz" in bitbake.conf so,
> unless you mess with it, the end result is a debugfs tarball under
> deploy/images. so far, so good.
>
>   now, if you (for no good reason) also set:
>
>   IMAGE_FSTYPES_DEBUGFS = ''
>
> in your local.conf, then even though you *claim* you want the debugfs,
> you're not going to get one since the build process has no idea what
> archive type you want. i believe this is the result of this snippet in
> image.bbclass in the anonymous python routine (line 369):
>
> if d.getVar('IMAGE_GEN_DEBUGFS') == "1":
> debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS').split()
> for t in debugfs_fstypes:
> alltypes.append("debugfs_" + t)
>
> which makes sense. however, even if you don't get the final debugfs
> tarball under deploy, i see that the *contents* of the debugfs are
> still generated under WORKDIR for the image (in my case,
> core-image-minimal), since i see both:
>
>   rootfs/
>   rootfs-dbg/
>
> and following the trail of bread crumbs to see where that came from, i
> ended up in meta/lib/oe/rootfs.py:
>
> def _setup_dbg_rootfs(self, dirs):
> gen_debugfs = self.d.getVar('IMAGE_GEN_DEBUGFS') or '0'
> if gen_debugfs != '1':
>return
>
> bb.note("  Renaming the original rootfs...")
> try:
> shutil.rmtree(self.image_rootfs + '-orig')
> except:
> pass
> bb.utils.rename(self.image_rootfs, self.image_rootfs + '-orig')
>
> ... and so on and so on ...
>
> which clearly(?) does all that work, even if, in the end, the result
> is not packaged as a tarball, which is part of what muh colleagues
> were asking about -- where can they see *exactly* how that debugfs
> content is collected?
>
>   is all this reasonably accurate so far?

Yes, I think so. Creation of the debugfs tar file uses a lot of the
same logic as creation of the rootfs image(s) so is controlled by
similar variables (e.g. IMAGE_FSTYPES_DEBUGFS is the equivalent of
IMAGE_FSTYPES). In theory you could change IMAGE_GEN_DEBUGFS to create
(for example) a squashfs image containing the debug symbols, but since
the debug symbols are going to be used on the host (and not copied
into Flash on the target etc) it doesn't make much sense to do so. In
practice the only reason you might want to change the default value of
IMAGE_GEN_DEBUGFS would be if you prefer .tar.bz2 etc over .tar.gz.

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



Re: [OE-core] master/main branch renaming and bitbake

2021-05-12 Thread Andre McCurdy
On Wed, May 12, 2021 at 2:23 PM Alexander Kanavin
 wrote:
>
> And by the way, another reason to check that revision is linked to a branch 
> is when SRCREV is updated - we need some reassurance that the updated SRCREV 
> comes from the same branch as previous SRCREV, or that if the branch has 
> changed, it's explicitly visible in the diff and explained in the commit 
> message.

None of the answers given so far seem very convincing...

If the git revision that a recipe wants is available on an unexpected
branch in the upstream repo then it's not really different from a tar
file being fetched from a mirror rather than whatever is in SRC_URI.
If we want the fetcher to fail as an indication that an upstream git
repo has renamed branches then don't we also want it to fail if a tar
file disappears from an upstream server? It seems odd that one should
be a fatal error and the other to be something we try to cover up and
hide from the end user.

Anyway, for recipes which don't explicitly specify a branch in SRC_URI
it would seem quite reasonable for the fetcher to check what the
default branch is set to in the upstream repo and search for the
required git revision in that branch (rather than rely on a hardcoded
default of "master" as we do now). Going forward, there's going to be
less standardisation on what upstream repos call their default branch,
so we're either going to have to explicitly specify a branch in more
and more recipes or teach the fetcher to automatically figure out what
the default branch in the upstream repo is.

> Alex
>
> On Wed, 12 May 2021 at 23:17, Alexander Kanavin  
> wrote:
>>
>> On Wed, 12 May 2021 at 22:44, Colin Walters  wrote:
>>>
>>> On Wed, May 12, 2021, at 4:40 PM, Alexander Kanavin wrote:
>>> > For ostree, yes:
>>> > http://git.openembedded.org/meta-openembedded/log/?h=master-next
>>> >
>>> > For the generic case, no. It's not a good idea to start guessing what
>>> > the upstream did.
>>>
>>> What is the goal of the `branch=` specification?  I can understand it being 
>>> *informative* for humans specifically when things like non-master/main 
>>> branches e.g. `release-4.x`, `lts-`, `stable-` etc. are involved.
>>>
>>> But why is bitbake explicitly checking it?  Is it to validate what the 
>>> human expressed, or is it to try to cover some security aspect?  Something 
>>> else?
>>
>>
>> To ensure the specified revision is actually linked with the specified 
>> branch, and not just free-floating, and catch branch renames, deletions and 
>> force pushes. You can override that behaviour with nobranch=1, at your own 
>> risk - free-floating revisions can be 'garbage collected'.
>>
>> Yes, it's annoying when the upstream renames branches, but it's no different 
>> than upstreams clearing up old tarballs, or disappearing altogether. Ensure 
>> you have proper download mirrors.
>>
>> Alex
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151693): 
https://lists.openembedded.org/g/openembedded-core/message/151693
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] npth: Link with libpthread

2021-05-12 Thread Andre McCurdy
On Wed, May 12, 2021 at 12:25 PM Khem Raj  wrote:
>
> libnpth.so uses pthread_create so ensure its linked in
>
> Fixes
>
> tmp/work/core2-32-yoe-linux/npth/1.6-r0/recipe-sysroot-native/usr/bin/i686-yoe-linux/i686-yoe-linux-ld:
>  ../src/.libs/libnpth.so: undefined reference to `pthread_create'

Seems like something which should be fixed by a patch to the source
code (and submitted upstream).

> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-support/npth/npth_1.6.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-support/npth/npth_1.6.bb 
> b/meta/recipes-support/npth/npth_1.6.bb
> index 94a3f00eac..7b3ad0c95d 100644
> --- a/meta/recipes-support/npth/npth_1.6.bb
> +++ b/meta/recipes-support/npth/npth_1.6.bb
> @@ -18,6 +18,8 @@ BINCONFIG = "${bindir}/npth-config"
>
>  inherit autotools binconfig-disabled multilib_header
>
> +LDFLAGS += "-pthread"
> +
>  FILES_${PN} = "${libdir}/libnpth.so.*"
>  FILES_${PN}-dev += "${bindir}/npth-config"
>
> --
> 2.31.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151674): 
https://lists.openembedded.org/g/openembedded-core/message/151674
Mute This Topic: https://lists.openembedded.org/mt/82781434/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] SDK question: does "-c populate_sdk" build SDK based on entire image?

2021-05-07 Thread Andre McCurdy
On Fri, May 7, 2021 at 6:47 AM Robert P. J. Day  wrote:
>
> On Fri, 7 May 2021, Quentin Schulz wrote:
>
> > Hi Robert,
> >
> > No SDK expert here, so as usual, to be taken with a grain of salt.
> >
> > On Fri, May 07, 2021 at 09:11:37AM -0400, Robert P. J. Day wrote:
> > >
> > >   almost certainly a silly question as i'm still poring over the
> > > mechanics of standard SDK creation, but if i define a perfectly normal
> > > image, then build the corresponding SDK with:
> > >
> > >   $ bitbake -c populate_sdk my_image
> > >
> > > is the resulting SDK populated based on the entire contents of the
> > > target image? that is, if i subsequently add a new package to the
> > > target and rebuild the SDK, will the new SDK now contain the
> > > corresponding content from that newly-added package? (i'm just about
> > > to test this with a build but that's going to take over an hour on
> > > this server. *sigh* ...)
> > >
> >
> > I think you're mixing SDK and eSDK. AFAIU so far, you're looking for
> > an eSDK. An SDK just gives you the minimal toolchain and associated
> > tools, to be able to compile something. I would go as far as saying
> > it's basically what a PC distro package for cross-compile with gcc
> > is doing.
>
>... snip ...
>
> it's slowly coming back to me, as i once examined the recipe
> meta-toolchain.bb for building a toolchain, whose contents are
> effectively:
>
>   inherit populate_sdk
>
> and when you run "bitbake meta-toolchain", you're obviously not
> supplying a particular image as an argument, so whatever is being done
> has to be based on fundamental information like MACHINE and so on,
> with no reference to a particular image so, yes, you'd get a "minimal"
> toolchain as you describe above independent of any image.
>
>   however, as populate_sdk.bbclass inherits populate_sdk_base.bbclass,
> and that latter class file contains:
>
> TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host 
> packagegroup-cross-canadian-${MACHINE}"
> TOOLCHAIN_HOST_TASK_ATTEMPTONLY ?= ""
> TOOLCHAIN_TARGET_TASK ?= "${@multilib_pkg_extend(d, 
> 'packagegroup-core-standalone-sdk-target')} target-sdk-provides-dummy"
> TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?= ""
> TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
>
> it seems clear that you can augment that minimal toolchain with
> exactly the two variables i mentioned earlier. ok, i think i've
> refreshed my memory on this. now off to figure out the eSDK.

Didn't we discuss exactly this (ie the difference between a pure SDK
recipe such as meta-toolchain and the populate_sdk task of an image
recipe) a couple of weeks ago?

Both are valid ways to create an SDK and there are no rules about one
or the other being specific to creating a "minimal" toolchain.
Basically a pure SDK recipe gives you full control while the
populare_sdk task of an image recipe is easier to set up (no new
recipe to write) at the expense of the final SDK containing extra junk
such as busybox init scripts, etc which are needed in the image but
not an SDK.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151460): 
https://lists.openembedded.org/g/openembedded-core/message/151460
Mute This Topic: https://lists.openembedded.org/mt/82654706/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] how to add a "-dev" package to host SDK?

2021-05-03 Thread Andre McCurdy
On Mon, May 3, 2021 at 7:55 AM Robert P. J. Day  wrote:
>
>   colleague asks a simple question (and i'm not in front of my dev box
> at the moment so i can't verify what i'm about to suggest): how to add
> the header files in a given "-dev" package to the host component of
> the SDK?

The implication of that is that you want to use a header file from a
host component of the SDK to be able to compile additional tools etc
to run on the host after the SDK has been created?

Normally the SDK tools etc which run on the host are all compiled as
part of creating the SDK, not afterwards.

>   i haven't spent a lot of time messing with SDKs (that is about to
> change), but as i read it, if one wants to add the contents of any
> given development package to the host SDK, it would look like:
>
>   TOOLCHAIN_HOST_TASK_append = " nativesdk-fubar-dev"
>
>   i have no idea what the rationale is here, i'm just trying to
> address the question, which in addition asks, "if you add something
> like that to the host side, is it automatically added to the target
> side?"

It's not.

>   i'm pretty sure it isn't, but i can check that after i log in. i
> have no idea what they're up to here, i just want to answer the
> question.
>
> rday
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151220): 
https://lists.openembedded.org/g/openembedded-core/message/151220
Mute This Topic: https://lists.openembedded.org/mt/82553343/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] busybox: Enable long options for enabled applets

2021-04-29 Thread Andre McCurdy
On Thu, Apr 29, 2021 at 3:29 PM Khem Raj  wrote:
>
> On Wed, Apr 28, 2021 at 10:40 AM Andre McCurdy  wrote:
> >
> > On Tue, Apr 27, 2021 at 10:06 PM Khem Raj  wrote:
> > >
> > > certain applets are enabled but the long options are not enabled for
> > > them, it results in subtle failures in ptests where its expecting these
> > > options e.g. gzip --best is commonly used in many package tests e.g.
> > >
> > > root@qemux86-64:/usr/lib# grep -r "\-\-best" *
> > > acl/ptest/Makefile:GZIP_ENV = --best
> > > attr/ptest/Makefile:GZIP_ENV = --best
> > > coreutils/ptest/Makefile:GZIP_ENV = --best
> > > ethtool/ptest/Makefile:GZIP_ENV = --best
> > > libxml2/ptest/Makefile:GZIP_ENV = --best
> > > lttng-tools/ptest/Makefile:GZIP_ENV = --best
> > > opkg/ptest/Makefile:GZIP_ENV = --best
> > > perl/ptest/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm:COMPRESS 
> > > ('gzip --best')
> > > python3.9/test/test_gzip.py:for compress_level in ('--fast', 
> > > '--best'):
> > > ...
> > >
> > > this ensures that these options are enabled by default, which makes them 
> > > more
> > > compatible than now with coreutils provided utilities
> > >
> > > busybox size grows by 4K which perhaps is acceptable
> > >
> > > --rwxr-xr-x root   root   817704 ./bin/busybox.nosuid
> > > +-rwxr-xr-x root   root   821800 ./bin/busybox.nosuid
> > >
> > > This makes autopoint-3/gettext pass
> > >
> > > Signed-off-by: Khem Raj 
> > > ---
> > >  meta/recipes-core/busybox/busybox/getopts.cfg | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/meta/recipes-core/busybox/busybox/getopts.cfg 
> > > b/meta/recipes-core/busybox/busybox/getopts.cfg
> > > index 8db0a4a8f2..aeb5ac691f 100644
> > > --- a/meta/recipes-core/busybox/busybox/getopts.cfg
> > > +++ b/meta/recipes-core/busybox/busybox/getopts.cfg
> > > @@ -1,3 +1,10 @@
> > >  CONFIG_GETOPT=y
> > >  CONFIG_LONG_OPTS=y
> > >  CONFIG_FEATURE_GETOPT_LONG=y
> > > +CONFIG_FEATURE_GZIP_LONG_OPTIONS=y
> > > +CONFIG_FEATURE_TAR_LONG_OPTIONS=y
> > > +CONFIG_FEATURE_CHOWN_LONG_OPTIONS=y
> > > +CONFIG_FEATURE_CP_LONG_OPTIONS=y
> > > +CONFIG_FEATURE_INSTALL_LONG_OPTIONS=y
> > > +CONFIG_FEATURE_DIFF_LONG_OPTIONS=y
> > > +CONFIG_FEATURE_SETCONSOLE_LONG_OPTIONS=y
> >
> > What's the connection between enabling the getopt applet (a utility to
> > help with parsing options in shell scripts etc) and enabling support
> > for long options in a bunch of other unconnected apps?
> >
> > I think enabling support for long options in a particular app would be
> > better done where that app is enabled (e.g.
> > CONFIG_FEATURE_GZIP_LONG_OPTIONS should be enabled where CONFIG_GZIP
> > is enabled - in the defconfig file).
>
> I experimented a bit more and it seems that these options are tied to
> the corresponding feature being enabled
> so they can be enabled in a fragment, unless the feature itself is
> enabled it will be ignored and disabled. So for
> disabled features/applets these options are moot. So as such, I think
> enabling them is a good thing as it will
> widen the ecompatibility for busibox systems.

OK, so all that's left to do is to move them into their own config
fragment (since they have nothing to do with the existing getops
config fragment).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151124): 
https://lists.openembedded.org/g/openembedded-core/message/151124
Mute This Topic: https://lists.openembedded.org/mt/82422704/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] busybox: Enable long options for enabled applets

2021-04-28 Thread Andre McCurdy
On Tue, Apr 27, 2021 at 10:06 PM Khem Raj  wrote:
>
> certain applets are enabled but the long options are not enabled for
> them, it results in subtle failures in ptests where its expecting these
> options e.g. gzip --best is commonly used in many package tests e.g.
>
> root@qemux86-64:/usr/lib# grep -r "\-\-best" *
> acl/ptest/Makefile:GZIP_ENV = --best
> attr/ptest/Makefile:GZIP_ENV = --best
> coreutils/ptest/Makefile:GZIP_ENV = --best
> ethtool/ptest/Makefile:GZIP_ENV = --best
> libxml2/ptest/Makefile:GZIP_ENV = --best
> lttng-tools/ptest/Makefile:GZIP_ENV = --best
> opkg/ptest/Makefile:GZIP_ENV = --best
> perl/ptest/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm:COMPRESS 
> ('gzip --best')
> python3.9/test/test_gzip.py:for compress_level in ('--fast', 
> '--best'):
> ...
>
> this ensures that these options are enabled by default, which makes them more
> compatible than now with coreutils provided utilities
>
> busybox size grows by 4K which perhaps is acceptable
>
> --rwxr-xr-x root   root   817704 ./bin/busybox.nosuid
> +-rwxr-xr-x root   root   821800 ./bin/busybox.nosuid
>
> This makes autopoint-3/gettext pass
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-core/busybox/busybox/getopts.cfg | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/meta/recipes-core/busybox/busybox/getopts.cfg 
> b/meta/recipes-core/busybox/busybox/getopts.cfg
> index 8db0a4a8f2..aeb5ac691f 100644
> --- a/meta/recipes-core/busybox/busybox/getopts.cfg
> +++ b/meta/recipes-core/busybox/busybox/getopts.cfg
> @@ -1,3 +1,10 @@
>  CONFIG_GETOPT=y
>  CONFIG_LONG_OPTS=y
>  CONFIG_FEATURE_GETOPT_LONG=y
> +CONFIG_FEATURE_GZIP_LONG_OPTIONS=y
> +CONFIG_FEATURE_TAR_LONG_OPTIONS=y
> +CONFIG_FEATURE_CHOWN_LONG_OPTIONS=y
> +CONFIG_FEATURE_CP_LONG_OPTIONS=y
> +CONFIG_FEATURE_INSTALL_LONG_OPTIONS=y
> +CONFIG_FEATURE_DIFF_LONG_OPTIONS=y
> +CONFIG_FEATURE_SETCONSOLE_LONG_OPTIONS=y

What's the connection between enabling the getopt applet (a utility to
help with parsing options in shell scripts etc) and enabling support
for long options in a bunch of other unconnected apps?

I think enabling support for long options in a particular app would be
better done where that app is enabled (e.g.
CONFIG_FEATURE_GZIP_LONG_OPTIONS should be enabled where CONFIG_GZIP
is enabled - in the defconfig file).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151063): 
https://lists.openembedded.org/g/openembedded-core/message/151063
Mute This Topic: https://lists.openembedded.org/mt/82422704/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] LTP drop MUSL specific patch

2021-04-27 Thread Andre McCurdy
On Tue, Apr 27, 2021 at 12:17 PM Petr Vorel  wrote:
>
> Hi all,
>
> > On Mon, Apr 26, 2021 at 11:53 AM Petr Vorel  wrote:
>
> > > Hi Khem, Richard,
>
> > > I'd like to replace MUSL specific patch
> > > meta/recipes-extended/ltp/ltp/0001-build-Add-option-to-select-libc-implementation.patch
> > > with just removing broken files. We use this in upstream CI for Alpine, I 
> > > ported
> > > it to Buildroot [2], where works well. It's better because it does allow 
> > > to
> > > handle MUSL without rebasing this patch.
>
> > > I was looking into the docs, it looks to me that do_configure [3] might 
> > > be good hook
> > > to add it into. But it looks like by default it contains oe_runmake clean 
> > > [4].
> > > Or should I use different hook? And how to find the default content of 
> > > chosen
> > > hook? (if I need to extend it, I'll have to provide the original as well)
>
> > Changes to source files, including removing them, should be done as
> > part of the do_patch task. Since do_patch is implemented in python you
> > can't simply _append shell script commands to it, but you can add a
> > shell function via do_patch[postfuncs]. If you grep for
> > "do_patch[postfuncs]" in oe-core you should find a few examples.
>
> One more question: how to make this function MUSL specific?
> I noticed some functions has suffix "_libc-musl" (e.g.
> do_install_append_libc-musl), but I guess this would not work for
> do_patch[postfuncs], where I specify the name.

You can either use an intermediate variable in the recipe, e.g.

  PRUNESOURCE = ""
  PRUNESOURCE_libc-musl = "the-real-function"
  do_patch[postfuncs] += "${PRUNESOURCE}"

Or you can call the script unconditionally and check if [ "${TCLIBC}"
= "musl" ] from inside it.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151040): 
https://lists.openembedded.org/g/openembedded-core/message/151040
Mute This Topic: https://lists.openembedded.org/mt/82386051/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] LTP drop MUSL specific patch

2021-04-26 Thread Andre McCurdy
On Mon, Apr 26, 2021 at 11:53 AM Petr Vorel  wrote:
>
> Hi Khem, Richard,
>
> I'd like to replace MUSL specific patch
> meta/recipes-extended/ltp/ltp/0001-build-Add-option-to-select-libc-implementation.patch
> with just removing broken files. We use this in upstream CI for Alpine, I 
> ported
> it to Buildroot [2], where works well. It's better because it does allow to
> handle MUSL without rebasing this patch.
>
> I was looking into the docs, it looks to me that do_configure [3] might be 
> good hook
> to add it into. But it looks like by default it contains oe_runmake clean [4].
> Or should I use different hook? And how to find the default content of chosen
> hook? (if I need to extend it, I'll have to provide the original as well)

Changes to source files, including removing them, should be done as
part of the do_patch task. Since do_patch is implemented in python you
can't simply _append shell script commands to it, but you can add a
shell function via do_patch[postfuncs]. If you grep for
"do_patch[postfuncs]" in oe-core you should find a few examples.

> Thanks for info.
>
> Kind regards,
> Petr
>
> [1] https://github.com/linux-test-project/ltp/blob/master/travis/alpine.sh#L35
> [2] 
> https://git.busybox.net/buildroot/tree/package/ltp-testsuite/ltp-testsuite.mk#n72
> [3] 
> https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#new-dependencies
> [4] 
> https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-configure
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151017): 
https://lists.openembedded.org/g/openembedded-core/message/151017
Mute This Topic: https://lists.openembedded.org/mt/82386051/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] [yocto-security] [PATCH] busybox: use openssl for TLS connections whenever possible

2021-04-21 Thread Andre McCurdy
On Wed, Apr 21, 2021 at 2:22 AM Shachar Menashe  wrote:
> On Tue, Apr 20, 2021 at 1:46 PM Shachar Menashe  wrote:
>
> Last time we talked about this I thought we would need to change something in 
> openssl build settings to make the openssl binary get built just for this 
> solution, and that was what got rejected.
> But actually now I see (or perhaps it got changed) that the openssl binary is 
> built anyways, in any build that already relies on openssl.
> So my suggestion is to enable this feature. Like I said in builds with 
> openssl it will make everything more secure in a transparent manner, and in 
> builds without openssl it will display a warning just like today.
> I wouldn't consider it a hacky solution since this is the official solution 
> for this issue.
>
> It's very clearly a hack. Maybe it's the "official solution" for
> supporting https with busybox wget, but OE has a wider scope - we're
> not limited to busybox wget if a better overall solution is available.
>
> This is also exacerbated due to the fact that there are no other alternatives 
> for secure download from CLI (ex. the sato build doesn't contain the "curl" 
> standalone binary)
>
> I don't see an issue with adding curl to any OE reference image which
> needs an https client.
>
> OK, so do you suggest adding curl and removing wget? (that would be a patch 
> with a configuration change to busybox)

Yes, sounds good to me.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150751): 
https://lists.openembedded.org/g/openembedded-core/message/150751
Mute This Topic: https://lists.openembedded.org/mt/82240467/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] [yocto-security] [PATCH] busybox: use openssl for TLS connections whenever possible

2021-04-20 Thread Andre McCurdy
On Tue, Apr 20, 2021 at 1:46 PM Shachar Menashe  wrote:
>
> Last time we talked about this I thought we would need to change something in 
> openssl build settings to make the openssl binary get built just for this 
> solution, and that was what got rejected.
> But actually now I see (or perhaps it got changed) that the openssl binary is 
> built anyways, in any build that already relies on openssl.
> So my suggestion is to enable this feature. Like I said in builds with 
> openssl it will make everything more secure in a transparent manner, and in 
> builds without openssl it will display a warning just like today.
> I wouldn't consider it a hacky solution since this is the official solution 
> for this issue.

It's very clearly a hack. Maybe it's the "official solution" for
supporting https with busybox wget, but OE has a wider scope - we're
not limited to busybox wget if a better overall solution is available.

> This is also exacerbated due to the fact that there are no other alternatives 
> for secure download from CLI (ex. the sato build doesn't contain the "curl" 
> standalone binary)

I don't see an issue with adding curl to any OE reference image which
needs an https client.

> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150728): 
https://lists.openembedded.org/g/openembedded-core/message/150728
Mute This Topic: https://lists.openembedded.org/mt/82240467/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] [yocto-security] [PATCH] busybox: use openssl for TLS connections whenever possible

2021-04-20 Thread Andre McCurdy
On Tue, Apr 20, 2021 at 10:23 AM Randy MacLeod
 wrote:
>
> Add the oe-core list where patches are usually discussed.
>
> On 2021-04-17 10:41 a.m., Shachar Menashe wrote:
>
> This adds proper TLS verification to wget
>
> I think you should add some of the comments you made in the bugzilla here:
>
> ---
>
> By enabling the busybox feature: WGET_OPENSSL it means that in builds WITH 
> openssl (ex. sato)
> the issue will be completely fixed, and in builds WITHOUT openssl, busybox 
> will fallback
> to using the internal (insecure) client which will print out a message
> "note: TLS certificate validation not implemented" Note that busybox does not 
> rely in any way on the OpenSSL library
> (it just executes the standalone binary, if it is found) so
> we shouldn't have linkage issues is CONFIG_FEATURE_WGET_OPENSSL is enabled 
> but OpenSSL is not getting built.
>
> ---
>
> Thanks for the explanation.
> We could add a RSUGGESTS make the coupling more clear:
>
> http://docs.yoctoproject.org/ref-manual/variables.html?highlight=rrecommends#term-RSUGGESTS
>
> I don't use that feature at all and it's not widely used in oe-core so 
> hopefully someone
> opinionated will reply and help us out.
>
> ../Randy


> Signed-off-by: Shachar Menashe 
> ---
>  meta/recipes-core/busybox/busybox.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/busybox/busybox.inc 
> b/meta/recipes-core/busybox/busybox.inc
> index 47fcb59302..8f274bd263 100644
> --- a/meta/recipes-core/busybox/busybox.inc
> +++ b/meta/recipes-core/busybox/busybox.inc
> @@ -77,6 +77,7 @@ def features_to_busybox_settings(d):
>  busybox_cfg(bb.utils.contains('DISTRO_FEATURES', 'ipv4', True, False, 
> d), 'CONFIG_FEATURE_IFUPDOWN_IPV4', cnf, rem)
>  busybox_cfg(bb.utils.contains('DISTRO_FEATURES', 'ipv6', True, False, 
> d), 'CONFIG_FEATURE_IFUPDOWN_IPV6', cnf, rem)
>  busybox_cfg(bb.utils.contains_any('DISTRO_FEATURES', 'bluetooth wifi', 
> True, False, d), 'CONFIG_RFKILL', cnf, rem)
> +busybox_cfg(True, 'CONFIG_FEATURE_WGET_OPENSSL', cnf, rem)
>  return "\n".join(cnf), "\n".join(rem)
>
>  # X, Y = ${@features_to_busybox_settings(d)}
> --
> 2.17.1
>

This was discussed on the list last year. The conclusion was that
FEATURE_WGET_HTTPS should be disabled by default (ie giving anyone who
needs to fetch from https URLs to clear hint that that should be using
full featured wget or curl) rather than enabling a hacky solution to
have busybox call out to the openssl command line tool. Has something
changed since then?

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



Re: [OE-core] [PATCH 2/3] btrfs-tools: Add PACKAGECONFIG options

2021-04-16 Thread Andre McCurdy
On Fri, Apr 16, 2021 at 7:28 AM Robert Joslyn
 wrote:
> > On Apr 16, 2021, at 12:17 AM, Andre McCurdy  wrote:
> > On Thu, Apr 15, 2021 at 10:38 PM Robert Joslyn
> >  wrote:
> >>
> >> Add options to make it easier to control which features are enabled. All
> >> of these default to enabled by upstream, so keep them enabled to
> >> maintain previous behavior.
> >>
> >> The convert option also supports reiserfs, but no recipes exist in the
> >> layer index. Limit the option to ext filesystems until someone cares
> >> enough to make reiserfs recipes.
> >>
> >> Remove acl and attr from DEPENDS, as they do not apper to be needed. Add
> >> zlib since it is required.
> >>
> >> Signed-off-by: Robert Joslyn 
> >> ---
> >> .../btrfs-tools/btrfs-tools_5.11.1.bb | 26 ---
> >> 1 file changed, 23 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.11.1.bb 
> >> b/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.11.1.bb
> >> index 2ab476a88e..b875ea1aa1 100644
> >> --- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.11.1.bb
> >> +++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.11.1.bb
> >> @@ -13,7 +13,7 @@ LIC_FILES_CHKSUM = " \
> >> 
> >> file://libbtrfsutil/COPYING.LESSER;md5=3000208d539ec061b899bce1d9ce9404 \
> >> "
> >> SECTION = "base"
> >> -DEPENDS = "util-linux attr e2fsprogs lzo acl"
> >> +DEPENDS = "lzo util-linux zlib"
> >> DEPENDS_append_class-target = " udev"
> >> RDEPENDS_${PN} = "libgcc"
> >>
> >> @@ -22,17 +22,37 @@ SRC_URI = 
> >> "git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git \
> >>
> >> file://0001-Add-a-possibility-to-specify-where-python-modules-ar.patch \
> >>"
> >>
> >> -PACKAGECONFIG ??= "python"
> >> +PACKAGECONFIG ??= " \
> >> +${@bb.utils.filter('DISTRO_FEATURES', 'largefile', d)} \
> >
> > The largefile distro feature is for historical reference only. Recipes
> > should always enable largefile support regardless of the distro
> > feature (which will eventually be removed).
>
> Is it worth making it a PACKAGECONFIG at all, or is it preferred to just set 
> —enable-largefile in EXTRA_OECONF? The upstream configure script does enable 
> this by default so it’s not strictly needed at all either, but I usually 
> prefer to be more explicit with configure options (as you can probably tell 
> with this patch!).

Adding —enable-largefile to EXTRA_OECONF would be fine.

In general the goal of PACKAGECONFIG is not to expose every possible
configure option, but only the ones which we want to encourage people
to experiment with or use to control high level functionality. An
option to break support for large files doesn't fit into that
category.

> >> +backtrace \
> >> +programs \
> >> +shared \
> >> +convert \
> >> +python \
> >> +crypto-builtin \
> >
> > This is not conventional formatting for a list of PACKAGECONFIG
> > options. Maybe have a look at some other recipes in oe-core to get a
> > feel for the typical style.
>
> I’m not sure what you mean. Would you prefer them on one line rather than 
> split? In a specific order? There seems to be a lot of different styles in 
> use, so I tried to follow the OE style guide, which suggests splitting lists 
> like this, but maybe I’m misunderstanding.

My preference doesn't matter much :-) I was suggesting that you look
in oe-core to get a feel for the typical style. Note that the OE style
guide mostly predates PACKAGECONFIG and hasn't been updated to cover
it in any detail.

> >> +"
> >> +PACKAGECONFIG[largefile] = "--enable-largefile,--disable-largefile"
> >> +PACKAGECONFIG[backtrace] = "--enable-backtrace,--disable-backtrace"
> >> PACKAGECONFIG[manpages] = "--enable-documentation, 
> >> --disable-documentation, asciidoc-native xmlto-native"
> >> +PACKAGECONFIG[programs] = "--enable-programs,--disable-programs"
> >> +PACKAGECONFIG[shared] = "--enable-shared,--disable-shared"
> >> +PACKAGECONFIG[static] = "--enable-static,--disable-static"
> >
> > The choice to build shared and/or static libs is not something which
> > is typically controlled by PACKAGECONFIG options.
>
> Some recipes do use PACKAGECONFIG, such as ffmpeg, but in grepping the 

Re: [OE-core] [PATCH 2/3] btrfs-tools: Add PACKAGECONFIG options

2021-04-16 Thread Andre McCurdy
On Thu, Apr 15, 2021 at 10:38 PM Robert Joslyn
 wrote:
>
> Add options to make it easier to control which features are enabled. All
> of these default to enabled by upstream, so keep them enabled to
> maintain previous behavior.
>
> The convert option also supports reiserfs, but no recipes exist in the
> layer index. Limit the option to ext filesystems until someone cares
> enough to make reiserfs recipes.
>
> Remove acl and attr from DEPENDS, as they do not apper to be needed. Add
> zlib since it is required.
>
> Signed-off-by: Robert Joslyn 
> ---
>  .../btrfs-tools/btrfs-tools_5.11.1.bb | 26 ---
>  1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.11.1.bb 
> b/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.11.1.bb
> index 2ab476a88e..b875ea1aa1 100644
> --- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.11.1.bb
> +++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.11.1.bb
> @@ -13,7 +13,7 @@ LIC_FILES_CHKSUM = " \
>  file://libbtrfsutil/COPYING.LESSER;md5=3000208d539ec061b899bce1d9ce9404 \
>  "
>  SECTION = "base"
> -DEPENDS = "util-linux attr e2fsprogs lzo acl"
> +DEPENDS = "lzo util-linux zlib"
>  DEPENDS_append_class-target = " udev"
>  RDEPENDS_${PN} = "libgcc"
>
> @@ -22,17 +22,37 @@ SRC_URI = 
> "git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git \
> 
> file://0001-Add-a-possibility-to-specify-where-python-modules-ar.patch \
> "
>
> -PACKAGECONFIG ??= "python"
> +PACKAGECONFIG ??= " \
> +${@bb.utils.filter('DISTRO_FEATURES', 'largefile', d)} \

The largefile distro feature is for historical reference only. Recipes
should always enable largefile support regardless of the distro
feature (which will eventually be removed).

> +backtrace \
> +programs \
> +shared \
> +convert \
> +python \
> +crypto-builtin \

This is not conventional formatting for a list of PACKAGECONFIG
options. Maybe have a look at some other recipes in oe-core to get a
feel for the typical style.

> +"
> +PACKAGECONFIG[largefile] = "--enable-largefile,--disable-largefile"
> +PACKAGECONFIG[backtrace] = "--enable-backtrace,--disable-backtrace"
>  PACKAGECONFIG[manpages] = "--enable-documentation, --disable-documentation, 
> asciidoc-native xmlto-native"
> +PACKAGECONFIG[programs] = "--enable-programs,--disable-programs"
> +PACKAGECONFIG[shared] = "--enable-shared,--disable-shared"
> +PACKAGECONFIG[static] = "--enable-static,--disable-static"

The choice to build shared and/or static libs is not something which
is typically controlled by PACKAGECONFIG options.

> +PACKAGECONFIG[convert] = "--enable-convert 
> --with-convert=ext2,--disable-convert --without-convert,e2fsprogs"
>  PACKAGECONFIG[python] = 
> "--enable-python,--disable-python,python3-setuptools-native"
>  PACKAGECONFIG[zstd] = "--enable-zstd,--disable-zstd,zstd"
>
> +# Pick only one crypto provider
> +PACKAGECONFIG[crypto-builtin] = "--with-crypto=builtin"
> +PACKAGECONFIG[crypto-libgcrypt] = "--with-crypto=libgcrypt,,libgcrypt"
> +PACKAGECONFIG[crypto-libsodium] = "--with-crypto=libsodium,,libsodium"
> +PACKAGECONFIG[crypto-libkcapi] = "--with-crypto=libkcapi,,libkcapi"
> +
>  inherit autotools-brokensep pkgconfig manpages
>  inherit ${@bb.utils.contains('PACKAGECONFIG', 'python', 'distutils3-base', 
> '', d)}
>
>  CLEANBROKEN = "1"
>
> -EXTRA_OECONF_append_libc-musl = " --disable-backtrace "
> +PACKAGECONFIG_remove_libc-musl = "backtrace"

Use of _remove in core recipes is discouraged.

>  EXTRA_PYTHON_CFLAGS = "${DEBUG_PREFIX_MAP}"
>  EXTRA_PYTHON_CFLAGS_class-native = ""
>  EXTRA_PYTHON_LDFLAGS = "${LDFLAGS}"
> --
> 2.26.3
>
>
> 
>

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



Re: [OE-core] [PATCH] gcc: Upgrade to 10.3.0 bug-fix release

2021-04-09 Thread Andre McCurdy
On Fri, Apr 9, 2021 at 12:49 PM Khem Raj  wrote:
>
> Drop aarch64 backports which are already upstream
> List of bugs fixed is [1]
>
> [1] 
> https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED_id=298084=FIXED_milestone=10.3

It looks like you forgot to update BINV ?

> Signed-off-by: Khem Raj 
> ---

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

2021-04-09 Thread Andre McCurdy
On Fri, Apr 9, 2021 at 12:07 AM wangmy  wrote:
>
> I'm going to revise it like this. Please see if it's OK:
>
> @@ -54,6 +54,7 @@
>  PACKAGECONFIG[threaded-resolver] = 
> "--enable-threaded-resolver,--disable-threaded-resolverares"
>  PACKAGECONFIG[verbose] = "--enable-verbose,--disable-verbose"
>  PACKAGECONFIG[zlib] = "--with-zlib=${STAGING_LIBDIR}/../,--without-zlib,zlib"
> +PACKAGECONFIG[libgsasl] = "--with-libgsasl,--without-libgsasl,libgsasl"

The list of PACKAGECONFIG options is sorted, so the options for
libgsasl should be added between the options for ldaps and libidn, not
at the end after the options for zlib.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150330): 
https://lists.openembedded.org/g/openembedded-core/message/150330
Mute This Topic: https://lists.openembedded.org/mt/81935521/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 13/15] packagegroups: delete useless "PROVIDES" lines

2021-04-01 Thread Andre McCurdy
On Thu, Apr 1, 2021 at 8:29 AM Steve Sakoman  wrote:
>
> From: "Robert P. J. Day" 
>
> There is apparently no functional value to "PROVIDES" lines anymore in
> packagegroup recipe files, so remove the lonely couple of examples
> left.

Seems questionable for backporting to a stable release. The bogus
PROVIDES lines have been there for more than a decade without causing
any issues (ie removing them isn't fixing a bug).

> Signed-off-by: Robert P. J. Day > Signed-off-by: 
> Richard Purdie 
> (cherry picked from commit 6f2c9602bc5fc6794b852ec20f40ea62a55ada1e)
> Signed-off-by: Steve Sakoman 
> ---
>  meta/recipes-core/packagegroups/packagegroup-base.bb | 1 -
>  meta/recipes-core/packagegroups/packagegroup-core-nfs.bb | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb 
> b/meta/recipes-core/packagegroups/packagegroup-base.bb
> index 1f802da09b..c32664917f 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-base.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
> @@ -8,7 +8,6 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
>
>  inherit packagegroup
>
> -PROVIDES = "${PACKAGES}"
>  PACKAGES = ' \
>  packagegroup-base \
>  packagegroup-base-extended \
> diff --git a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb 
> b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> index b345e314ad..20fe6fc092 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> @@ -7,7 +7,6 @@ PR = "r2"
>
>  inherit packagegroup
>
> -PROVIDES = "${PACKAGES}"
>  PACKAGES = "${PN}-server ${PN}-client"
>
>  SUMMARY_${PN}-client = "NFS client"
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150171): 
https://lists.openembedded.org/g/openembedded-core/message/150171
Mute This Topic: https://lists.openembedded.org/mt/81779869/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] what are the dangers of adding "out-of-tree" files to FILES_${PN}?

2021-04-01 Thread Andre McCurdy
On Thu, Apr 1, 2021 at 6:08 AM Robert P. J. Day  wrote:
>
>   recently, i've run across a couple layers based on pretty much
> up-to-date OE/YP, where fixed files are being added to a package via
> assignments like this:
>
>   FILES_${PN} += "/data"
>
>   i already know that's a bad idea, but i'm curious as to what build
> errors might occur when trying something like this.

What's the specific concern? It won't work well for -native recipes
(as discussed in another of these threads), but apart from that it
should work OK.

To be safe for use in a -native recipe you could change it to:

  FILES_${PN} += "${base_prefix}/data"

> i was first asked
> about what might have caused a "pseudo abort" error as described here:
>
>   https://wiki.yoctoproject.org/wiki/Pseudo_Abort
>
> where the generated error referred to "path mismatch ... ino ###
> db" ... etc etc. my first (admittedly uneducated) guess was that, in
> the midst of installation, some of that external content under /data
> was perhaps being deleted or updated in some way that was changing
> inodes.

I don't think you can corrupt the pseudo database with a packaging rule.

>   even if doing something like technically works, can someone explain
> what ugliness might result, i'm assuming from having any of that
> external data change in the middle of a build?
>
> rday
>
>
>
> 
>

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



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

2021-03-29 Thread Andre McCurdy
On Mon, Mar 29, 2021 at 4:07 PM Devendra Tewari
 wrote:
>
> I did try that but got an error that does not happen when we try os.rename 
> first. I'll try to reproduce it again.
>
> I suspect there may be subtle differences in os.rename vs shutil.move with 
> respect to what happens when origin and/or destination do not exist or are 
> invalid.

If there are subtle issues which you don't yet understand then that's
all the more reason for not hiding the new shutil.move code behind a
test which will pass for 99.9% of users. Please figure that out before
sending another version of the patch.

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

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



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

2021-03-29 Thread Andre McCurdy
On Mon, Mar 29, 2021 at 3:45 PM Devendra Tewari
 wrote:
>
> Thanks! My bad. The example I looked up in Python docs had a break and I just 
> realized it was a looping example.
>
> Here’s the updated patch (or should I submit it again via git send-email?)

It would be better to use shutil.move unconditionally in all cases,
rather than have a separate shutil.move code path which only gets
tested by people doing incremental builds in docker.

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



Re: [OE-core] some trivial(?) questions about packagegroups

2021-03-27 Thread Andre McCurdy
On Sat, Mar 27, 2021 at 3:31 AM Robert P. J. Day  wrote:
> On Fri, 26 Mar 2021, Andre McCurdy wrote:
> > On Fri, Mar 26, 2021 at 8:45 AM Robert P. J. Day  
> > wrote:
> > >   what should be easy questions about packagegroups, inspired by my
> > > running across some puzzling packagegroup recipes in my travels
> > > recently. (i'll start with examples out of oe-core).
> > >
> > >   first, as with any other recipe, given a "trivial" packagegroup
> > > like, say, packagegroup-core-eclipse-debug.bb:
> > >
> > >   SUMMARY = "Remote debugging tools for Eclipse integration"
> > >
> > >   inherit packagegroup
> > >
> > >   RDEPENDS_${PN} = "\
> > > gdbserver \
> > > tcf-agent \
> > > openssh-sftp-server \
> > > "
> > >
> > > there is no need to add a "PROVIDES" line since every recipe file
> > > automatically provides its own name. so far, so good.
> > >
> > >   if we move up to packagegroup-core-nfs.bb, note how this recipe file
> > > defines two additional packagegroups, and has to add a PROVIDES line
> > > in order to make those new names accessible:
> > >
> > >   PROVIDES = "${PACKAGES}"
> > >   PACKAGES = "${PN}-server ${PN}-client"
> > >
> > >   SUMMARY_${PN}-client = "NFS client"
> > >   RDEPENDS_${PN}-client = "nfs-utils-client"
> > >
> > >   SUMMARY_${PN}-server = "NFS server"
> > >   RDEPENDS_${PN}-server = "\
> > > nfs-utils \
> > > nfs-utils-client \
> > > "
> > >
> > > so the question is, must one supply a PROVIDES line for any
> > > packagegroup names above and beyond the one that comes with the recipe
> > > file itself? i ask what seems like a dumb question as i've run across
> > > packagegroup recipe files that define multiple additional
> > > packagegroups, but do not add them to the PROVIDES line. what is that
> > > supposed to represent?
> >
> > PROVIDES sets up a name which can be used as DEPENDS (ie a build
> > time dependency) in other recipes. If PROVIDES contains more than
> > one name, they all just become aliases for each other.
> >
> > Since packagegroup recipes only define run time dependencies,
> > nothing should have a build time dependency on a packagegroup
> > recipe... and so there's no obvious reason to set PROVIDES to
> > anything. Leaving the default will be fine (although it won't be
> > used for anything).
>
>   i could have *sworn* that, once upon a time, i verified (in some
> weird way) the necessity for the PROVIDES line in a packagegroup, but
> it seems i was mistaken. so if this is the case, then why do a couple
> of OE packagegroup recipe files contain such a line?
>
>   packagegroup-base.bb
>   
>
>   inherit packagegroup
>
>   PROVIDES = "${PACKAGES}"   <=== ?

That line dates back to 2007, when packagegroup-base.bb was still
called task-base.bb:

  
https://git.openembedded.org/openembedded-core/commit/?id=ba9dd5228c290c96c622fb82964e49ce2511a1e9

Maybe it had some legitimate use back then?

Really the whole "base packagegroups" concept is showing its age. No
one creating a new machine config today ponders on whether or not to
enable the pci, pcmcia, phone, etc machine features.
packagegroup-base.bb contains a lot of useless cruft... the bogus
PROVIDES line is just the tip of the iceberg.

>   PACKAGES = ' \
> packagegroup-base \
> packagegroup-base-extended \
> packagegroup-distro-base \
> packagegroup-machine-base \
> ... etc etc ...
>
> surely this is not meant to alias all those distinct packagegroup
> definitions.
>
> rday
>
> p.s. see also,
> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150015): 
https://lists.openembedded.org/g/openembedded-core/message/150015
Mute This Topic: https://lists.openembedded.org/mt/81631340/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] some trivial(?) questions about packagegroups

2021-03-26 Thread Andre McCurdy
On Fri, Mar 26, 2021 at 8:45 AM Robert P. J. Day  wrote:
>
>   what should be easy questions about packagegroups, inspired by my
> running across some puzzling packagegroup recipes in my travels
> recently. (i'll start with examples out of oe-core).
>
>   first, as with any other recipe, given a "trivial" packagegroup
> like, say, packagegroup-core-eclipse-debug.bb:
>
>   SUMMARY = "Remote debugging tools for Eclipse integration"
>
>   inherit packagegroup
>
>   RDEPENDS_${PN} = "\
> gdbserver \
> tcf-agent \
> openssh-sftp-server \
> "
>
> there is no need to add a "PROVIDES" line since every recipe file
> automatically provides its own name. so far, so good.
>
>   if we move up to packagegroup-core-nfs.bb, note how this recipe file
> defines two additional packagegroups, and has to add a PROVIDES line
> in order to make those new names accessible:
>
>   PROVIDES = "${PACKAGES}"
>   PACKAGES = "${PN}-server ${PN}-client"
>
>   SUMMARY_${PN}-client = "NFS client"
>   RDEPENDS_${PN}-client = "nfs-utils-client"
>
>   SUMMARY_${PN}-server = "NFS server"
>   RDEPENDS_${PN}-server = "\
> nfs-utils \
> nfs-utils-client \
> "
>
> so the question is, must one supply a PROVIDES line for any
> packagegroup names above and beyond the one that comes with the recipe
> file itself? i ask what seems like a dumb question as i've run across
> packagegroup recipe files that define multiple additional
> packagegroups, but do not add them to the PROVIDES line. what is that
> supposed to represent?

PROVIDES sets up a name which can be used as DEPENDS (ie a build time
dependency) in other recipes. If PROVIDES contains more than one name,
they all just become aliases for each other.

Since packagegroup recipes only define run time dependencies, nothing
should have a build time dependency on a packagegroup recipe... and so
there's no obvious reason to set PROVIDES to anything. Leaving the
default will be fine (although it won't be used for anything).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149995): 
https://lists.openembedded.org/g/openembedded-core/message/149995
Mute This Topic: https://lists.openembedded.org/mt/81631340/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 v11] util-linux: split uuid in separate recipe to allow bootstrapping

2021-03-26 Thread Andre McCurdy
On Fri, Mar 26, 2021 at 11:12 AM Richard Purdie
 wrote:
>
> On Fri, 2021-03-26 at 18:06 +, Peter Kjellerstedt wrote:
> > > -Original Message-
> > > From: Richard Purdie 
> > > Sent: den 25 mars 2021 17:52
> > > To: Peter Kjellerstedt ; Oleksiy Obitotskyi -
> > > X (oobitots - GLOBALLOGIC INC at Cisco) ; Luca Bocassi
> > > ; openembedded-core@lists.openembedded.org
> > > Cc: bluelightn...@bluelightning.org; Khem Raj 
> > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
> > > recipe to allow bootstrapping
> > >
> > > On Thu, 2021-03-25 at 16:19 +, Peter Kjellerstedt wrote:
> > > > > -Original Message-
> > > > > From: Richard Purdie 
> > > > > Sent: den 25 mars 2021 15:27
> > > > > To: Peter Kjellerstedt ; Oleksiy
> > > Obitotskyi -
> > > > > X (oobitots - GLOBALLOGIC INC at Cisco) ; Luca
> > > Bocassi
> > > > > ; openembedded-core@lists.openembedded.org
> > > > > Cc: bluelightn...@bluelightning.org; Khem Raj 
> > > > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
> > > > > recipe to allow bootstrapping
> > > > >
> > > > > On Thu, 2021-03-25 at 14:22 +, Peter Kjellerstedt wrote:
> > > > > > > -Original Message-
> > > > > > > From: Richard Purdie 
> > > > > > > Sent: den 25 mars 2021 10:34
> > > > > > > To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
> > > > > > > ; Luca Bocassi ;
> > > > > > > openembedded-core@lists.openembedded.org
> > > > > > > Cc: bluelightn...@bluelightning.org; Peter Kjellerstedt
> > > > > > > ; Khem Raj 
> > > > > > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in
> > > separate
> > > > > > > recipe to allow bootstrapping
> > > > > > >
> > > > > > > On Thu, 2021-03-25 at 09:17 +, Oleksiy Obitotskyi -X (oobitots
> > > -
> > > > > > > GLOBALLOGIC INC at Cisco) wrote:
> > > > > > > > Could you look into this warning.
> > > > > > > >
> > > > > > > > WARNING: util-linux-2.36.2-r0 do_package_qa: QA Issue: util-
> > > linux-
> > > > > dev
> > > > > > > rdepends on util-linux-libuuid-dev, but it isn't a build
> > > dependency?
> > > > > > > [build-deps]
> > > > > > > >
> > > > > > > >
> > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226
> > > > > > >
> > > > > > > That failure was my fault when testing some fixes.
> > > > > > >
> > > > > > > I've sent out a patch which renames util-linux-uuid to util-linux-
> > > > > libuuid
> > > > > > > and sorts out the license issue Peter reported.
> > > > > >
> > > > > > I don't mind the recipe being renamed and cleaned up, but I would
> > > prefer
> > > > > > to see my entire patch for the license parts being either integrated
> > > > > before
> > > > > > this or squashed into it, whichever you prefer. It does not make
> > > sense
> > > > > to
> > > > > > use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-
> > > linux,
> > > > > > and setting the other LICENSE variables in util-linux.inc no longer
> > > > > makes
> > > > > > sense as they are only relevant for util-linux.
> > > > >
> > > > > I'm torn on that. Code with the other licenses is present, just not
> > > used
> > > > > in the final output and I personally suspect that having one
> > > LIC_FILES_CHKSUM
> > > > > is going to be easier to maintain in the future rather than two
> > > separate
> > > > > ones.
> > > >
> > > > I actually checked all the files that go into -dev and -src before
> > > suggesting
> > > > this change, and all files are either marked as public domain or use a
> > > > BSD-3-Clause license.
> > >
> > > There is a difference between what ends up in ${S} and what ends up in the
> > > binary packages. LICENSE clearly governs the latter. Its the scope of
> > > LIC_FILES_CHECKSUM which there are differences of opinion on.
> >
> > Well, the latter governs what ends up in ${PN}-lic, so having a lot of
> > unrelated (to the installed packages) license files in LIC_FILES_CHECKSUM
> > does not make sense (to me). If everything that is built and (possibly)
> > installed and thus distributed is covered by BSD-3-Clause licenses, why
> > should ${PN}-lic include a lot of license files for unrelated code?
>
> I hadn't considered ${PN}-lic :(.
>
> We can't win. If we change LIC_FILES_CHKSUM we'll see complaints from
> people scanning the code that there are licenses present in WORKDIR that
> are not in LIC_FILES_CHKSUM.

If there's code in the upstream tar file etc which is not involved at
all in the build of the one particular sub component you're interested
in then this type of complaint can be solved by removing the unused
code from ${S} as part of do_patch.

> If we don't change it, ${PN}-lic does give
> more information than necessary. I still think the latter is probably
> safer and makes recipe upgrades easier.
>
> Licensing in general needs a step back and an overhaul. Sadly people are
> generally only prepared to do this piecemeal solving their specific
> issue rather than the general case and big picture.
>
> Cheers,
>
> 

Re: [OE-core] [PATCH 1/2] bitbake.conf: ensure BUILD_* tools match target tools

2021-03-23 Thread Andre McCurdy
On Tue, Mar 23, 2021 at 2:29 PM Ross Burton  wrote:
>
> Add a few more tools to the BUILD_* list, to match the target tool list.
>
> Signed-off-by: Ross Burton 
> ---
>  meta/conf/bitbake.conf | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index ecd4d1638e..d4bda80736 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -541,7 +541,10 @@ export BUILD_AR = "${BUILD_PREFIX}ar"
>  export BUILD_AS = "${BUILD_PREFIX}as ${BUILD_AS_ARCH}"
>  export BUILD_RANLIB = "${BUILD_PREFIX}ranlib"
>  export BUILD_STRIP = "${BUILD_PREFIX}strip"
> +export BUILD_OBJCOPY = "${BUILD_PREFIX}objcopy"
> +export BUILD_OBJDUMP = "${BUILD_PREFIX}objdump"
>  export BUILD_NM = "${BUILD_PREFIX}nm"
> +export BUILD_READELF = "${BUILD_PREFIX}readelf"

Do these new variables need to be exported?

As far as I remember a few of the BUILD_xxx variables are "official"
autotools variables which some autotools packages may expect to find
in the environment (although googling now doesn't find any
references).

If so then the rest (i.e. most of them, and certainly these newly
added ones) are OE specific and only used in OE recipes and classes...
and therefore don't need to be exported here.

>  export MAKE = "make"
>  EXTRA_OEMAKE = ""
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149848): 
https://lists.openembedded.org/g/openembedded-core/message/149848
Mute This Topic: https://lists.openembedded.org/mt/81562047/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] proper (vs weird) way to define proprietary licenses

2021-03-23 Thread Andre McCurdy
On Tue, Mar 23, 2021 at 3:13 AM Robert P. J. Day  wrote:
>
>   once again into the code base i'm poring over, and this time, it's
> about defining proprietary licenses for internal recipes.

The typical approach for recipes which build proprietary code is to
set LICENSE to "CLOSED" (and not define LIC_FILES_CHKSUM).

I'm not sure what the advantages are of creating a license text for a
proprietary license (since presumably you won't be sharing the source
or license text with anyone). However, if you do need to do that for
some reason, be sure to double check COPYLEFT_LICENSE_EXCLUDE (e.g.
append your proprietary license to it from your layer.conf) in avoid
someone enabling the archiver class and accidentally including your
proprietary code in a release of the open source code used in a
project.

>   turns out the meta-boundary layer has a nice example of what i'm
> sure is the right way to do this (i've rarely had to do this myself),
> wherein the layer's "layer.conf" file defines where to go get some
> extra licenses:
>
>   LICENSE_PATH += "${LAYERDIR}/licenses"
>
> or possibly some variant like (for ubiquitous acme corp.):
>
>   LICENSE_PATH += "${LAYERDIR}/files/acme-licenses"
>
> to pair up with OE's .../files/common-licenses, you get the idea.
>
>   so i was puzzled when i saw all these clearly proprietary recipes
> that did not define LICENSE or LIC_FILES_CHKSUM values but, instead,
> inherited "acme-license.bbclass", whereupon ... well ...
>
> acme-license.bbclass
> 
>
>   HOMEPAGE = "https://acme.com;
>   LICENSE  = "Acme-Corp-License"
>   LIC_FILES_CHKSUM =
> "file://${THISDIR}/../../files/acme-licenses/${LICENSE};
> md5=deadbeef..."
>
> *sigh* ... while this might save a couple lines per recipe file, i
> can't believe this is a reasonable approach. has anyone else seen this
> strategy?

Doesn't seem too unreasonable (aside from the comments above about
setting LICENSE to "CLOSED" for proprietary recipes).

>   in any event, i'm adding this to my current list of "stuff you might
> want to avoid doing when using openembedded."
>
> rday
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149840): 
https://lists.openembedded.org/g/openembedded-core/message/149840
Mute This Topic: https://lists.openembedded.org/mt/81547273/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] really strange usage of FILESPATH and FILESEXTRAPATHS

2021-03-22 Thread Andre McCurdy
On Mon, Mar 22, 2021 at 2:29 PM Robert P. J. Day  wrote:
>
>   here's the next head-scratching oddity i just ran across in the
> current layer (and there's more weirdness on its way).
>
>   perusing a recipe only to see:
>
>   FILESPATH =+ "${COMMON_STUFF_DIR}:"
>   SRC_URI += "file://file1 file://file2 file://file 3 ... etc ..."
>
> ok ... apparently, there are a number of recipes that want access to
> some small set of common files, so the solution(?) was to put those
> common files in some (out-of-layer) directory, and prepend to
> FILESPATH in each of those recipe files so that SRC_URI could find
> them.
>
>   i am not going to ask if this is some wickedly clever trick, since
> it can't be. it just can't.

It's unconventional, but I guess it will work OK (i.e. it won't have
any surprising or negative side effects).

It's better than (for example) one recipe fetching source from the
build directory of another recipe - which obviously breaks if you
don't somehow guarantee the order in which recipes are (re)built. I've
seen projects which did things like that and then needed to disable
sstate for CI and release builds as a workaround...

>   even stranger, one of the common files was a configuration script
> that contributed the line:
>
>   . config.sh
>
> to the top of a number of common tasks like do_configure, do_compile,
> do_install and so on.

It's not clear how a common file in SRC_URI could affect any tasks?

>   a similar tactic was to find this line in a class file:
>
>   FILESEXTRAPATHS_prepend := "${COMMON_STUFF_DIR}:"
>
> my head hurts.
>
>   first, if i needed to do something in common at the beginning of
> some basic tasks, i'd invent a bbclass file that "_prepend"ed to those
> tasks, and just inherit it when necessary.
>
>   as for a number of recipes needing access to common files for any
> reason, well, thoughts? my first thought is to encapsulate those files
> in a separate recipe, then make that recipe a build dependency so that
> those files would be available from the sysroot, but i'm sure there
> are better ideas.

Build dependencies are heavily geared towards libraries and header
files rather than common source files. See SYSROOT_DIRS and
SYSROOT_DIRS_BLACKLIST in staging.bbclass, which limit which
directories get staged in sysroot. You would need to navigate your way
around that (e.g. ensuring that the common source files get staged in
sysroot without being included in the final image, etc). Certainly
doable, but I guess too far up the OE learning cliff for most typical
users.

Adding the common source files to SRC_URI for each recipe which needs
them (whether as individual files from a local directory, as in your
example, or as a single tar file or git repo from a remote server) is
probably the better approach.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149804): 
https://lists.openembedded.org/g/openembedded-core/message/149804
Mute This Topic: https://lists.openembedded.org/mt/81536884/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 weirdness of bbappend'ing to stock OE images

2021-03-22 Thread Andre McCurdy
On Mon, Mar 22, 2021 at 12:50 PM Robert P. J. Day  wrote:
>
>
>   more a style issue than anything else, but one of the other oddities
> in this layer i've been handed is the bbappending to standard OE
> images, so that recipes-core/images/ contains recipe files like:
>
>   core-image-minimal.bbappend
>   core-image-minimal-dev.bbappend
>
> and so on. that just creeps me out -- my plan is to forcefully advise
> people to leave the stock images alone, and create clearly internal,
> proprietary ones, like:
>
>   acme-core-image-minimal.bb

A clearly internal proprietary image would remove the reference to
oe-core from the image name, so "acme-image-minimal.bb" rather than
"acme-core-image-minimal.bb".

> that inherit or include, then do the adjusting.
>
>   or is that approach considered acceptable? (it just makes me cringe,
> personally.)

I don't know. Adding to the core images doesn't seem like the worst
thing someone could do. After all, it's normal to add to or modify the
package groups which go into the core images (either directly or
indirectly by changing distro features).

Creating your own dedicated images is cleaner and clearer though.

> rday
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149797): 
https://lists.openembedded.org/g/openembedded-core/message/149797
Mute This Topic: https://lists.openembedded.org/mt/81534425/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] curious about weirdness in some FILES_${PN} settings

2021-03-22 Thread Andre McCurdy
On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day  wrote:
>   (warning: i've just been handed an existing OE code base, and i'm
> going to ask some questions about some head-scratching things i'm
> finding in it, so be prepared for weird questions.)
>
>   in one recipe, i see the following snippet:
>
>   FILES_${PN} += "/etc"
>   FILES_${PN} += "/etc/mosquitto"
>   FILES_${PN} += "/etc/mosquitto/config"
>   ... etc etc ...
>
> first, i'm taken aback by the hardcoding of "/etc" rather than using,
> you know, "${sysconfdir}", so i'm *assuming* that unless someone was
> doing something spectacularly clever here, that just can't be right.

Nothing clever going on, it's just a bug. In general, using /etc
instead of ${sysconfdir} etc will appear to work fine until you add
BBCLASSEXTEND and try to build -native, at which point things
will start to fail in mysterious ways (since native.bbclass over-rides
the default values of ${sysconfdir} etc).

In this particular case, you might still get away with it since
FILES_${PN} is related to packaging and -native recipes don't do any
packaging but it's still not right.

>   more to the point, the above seems redundant -- once you've added
> "/etc", isn't the rest just superfluous? i'm not sure what the
> original developer was going for here. thoughts?

Yes, and even beyond that, ${sysconfdir} is handled by the default
packaging rules, so any extra packaging rules related to adding files
from /etc to the default package are redundant.

>   finally, if i wanted to add all of some directory, say "dir", it was
> my understanding that all of the following were equivalent (h,
> short of picking up hidden files, i guess):
>
>   dir
>   dir/
>   dir/*
>
> my personal preference would be "dir/", as it gets across the idea
> that "dir" is a directory and i want all of it. thoughts on that as
> well? i'm currently perusing the OE code base to see the general
> consensus on this. is there one?

That's more a question of coding style, which the OE maintainers etc
generally doesn't care about very much (unless you start asking about
unifying oe-core and meta-oe with respect to indenting with tabs or
spaces...).

>   more decidedly strange questions coming shortly ...
>
> rday
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149795): 
https://lists.openembedded.org/g/openembedded-core/message/149795
Mute This Topic: https://lists.openembedded.org/mt/81532778/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] diff between "bitbake meta-toolchain" and "bitbake -c populate_sdk ?

2021-03-19 Thread Andre McCurdy
On Fri, Mar 19, 2021 at 7:23 AM Robert P. J. Day  wrote:
>   colleague just asked me about the difference between building an SDK
> with either of:
>
>   $ bitbake meta-toolchain
>   $ bitbake -c populate_sdk 
>
> i know that the meta-toolchain recipe file contains little more than
> inheriting populate_sdk so, without checking, i speculated wildly as
> follows:
>
>   "bitbake meta-toolchain" takes no target, so it's limited to
> whatever info it can glean from local.conf and bitbake.conf and so on
> and so on, things like MACHINE and DISTRO, and whatever assignments to
> TOOLCHAIN_HOST_TASK, etc, it runs into in its travels; in essence,
> it's a "generic" toolchain.

It's an example of a "pure" toolchain recipe. You are free to modify
it and add additional packages or use it as a reference to create your
own toolchain recipe. Here's another example of a pure toolchain
recipe from my current project:

  SUMMARY = "Installable toolchain for SK"
  LICENSE = "MIT"

  inherit populate_sdk

  TOOLCHAIN_TARGET_TASK_append = " packagegroup-sk-build-deps"

(As a side note, LICENSE still seems to be required in toolchain
recipes even though it's not in image recipes... it's a bug).

>   on the other hand, "bitbake -c populate_sdk " can, in
> addition, consult the target recipe file where it can collect even
> further SDK defining info, like what you find in core-image-sato.bb:

You mean  instead of . I don't think you can
create a toolchain from a normal recipe.

> TOOLCHAIN_HOST_TASK_append = " nativesdk-intltool nativesdk-glib-2.0"
>
>   at the risk of over-simplification, is that a not wholly inaccurate
> explanation of the difference?

Sounds about right. Note that using the populate_sdk task for an image
recipe means your toolchain will contain some extra junk (e.g.
busybox, etc) which isn't required and won't be there in toolchains
created from a pure toolchain recipe (since in a pure toolchain recipe
you have direct control over TOOLCHAIN_TARGET_TASK).

They both basically do the same but the populate_sdk task for an image
recipe automatically sets TOOLCHAIN_TARGET_TASK and
TOOLCHAIN_HOST_TASK for you based on the contents of the image whereas
with a pure toolchain recipe you are responsible for controlling these
explicitly (or leaving them alone, in which case you'll get a minimal
toolchain, as you do with the meta-toolchain recipe (horrible naming
IMO)).

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



Re: [OE-core] [PATCH 2/2] core-image-sato: qemuarmv5 doesn't work with >256M RAM

2021-03-10 Thread Andre McCurdy
On Wed, Mar 10, 2021 at 7:16 PM Jon Mason  wrote:
>
> On Wed, Mar 10, 2021 at 6:30 PM Andre McCurdy  wrote:
> >
> > On Wed, Mar 10, 2021 at 3:04 PM Jon Mason  wrote:
> > >
> > > Currently seeing the following error when running runqemu on qemuarmv5:
> > > runqemu - ERROR - Failed to run qemu: qemu-system-arm: versatilepb: 
> > > memory size must not exceed 256MB
> > >
> > > This is due to the memory size being set to 512 instead of the max
> > > allowable of 256.  Limit to this and everything is happy.
> > >
> > > Signed-off-by: Jon Mason 
> > > Change-Id: I3339e50a53464b95f52a987ed37868ebf0935b07
> > > ---
> > >  meta/recipes-sato/images/core-image-sato.bb | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/meta/recipes-sato/images/core-image-sato.bb 
> > > b/meta/recipes-sato/images/core-image-sato.bb
> > > index e50b24a47691..8ed8f75e9f92 100644
> > > --- a/meta/recipes-sato/images/core-image-sato.bb
> > > +++ b/meta/recipes-sato/images/core-image-sato.bb
> > > @@ -14,3 +14,4 @@ TOOLCHAIN_HOST_TASK_remove_task-populate-sdk-ext = " 
> > > nativesdk-intltool nativesd
> > >
> > >  QB_MEM = '${@bb.utils.contains("DISTRO_FEATURES", "opengl", "-m 512", 
> > > "-m 256", d)}'
> > >  QB_MEM_qemumips = "-m 256"
> > > +QB_MEM_qemuarmv5 = "-m 256"
> >
> > Grepping for QB_MEM suggests there are other images which need the
> > same fix. Maybe good to fix all of them at once rather than one at a
> > time.
>
> I do not know if other machines have this same issue with qemu

It's not related to other machines. There are other images which set
QB_MEM to "-m 512" based on the opengl distro feature. If
qemu-system-arm versatilepb can only support 256MB then these images
need to force QB_MEM to 256MB in the same way that you have done for
core-image-sato.

Cleaning up QB_MEM and how the qemu machine configs may more cleanly
control it is a separate issue.

>, and
> this is probably not the best way to resolve this (as I really think
> this should be part of the machine config file, and have runqemu be
> smarter logic about setting the memory size).  I can open a bug in
> bugzilla and get back to it later.
>
> >
> > > 2.20.1
> > >
> > >
> > > 
> > >

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



Re: [OE-core] [PATCH 1/2] qemuarmv5: add softfp

2021-03-10 Thread Andre McCurdy
On Wed, Mar 10, 2021 at 7:09 PM Jon Mason  wrote:
>
> On Wed, Mar 10, 2021 at 6:25 PM Andre McCurdy  wrote:
> >
> > On Wed, Mar 10, 2021 at 3:04 PM Jon Mason  wrote:
> > >
> > > pulseaudio-14.2 is throwing the following error when compiling for
> > > machine qemuarmv5
> > > "NEON intrinsics not available with the soft-float ABI.  Please use 
> > > -mfloat-abi=softfp or -mfloat-abi=hard"
> > >
> > > Using softfp to resolve this issue.
> >
> > Wouldn't "sidestep" be a more accurate description then "resolve" ?
> >
> > Either way I'm not sure that changing qemuarmv5 just to workaround one
> > broken package is the right approach. Doesn't it mean OE will no
> > longer have any test coverage for ARM soft float?
>
> With these obvious issues, no one is even compiling these, let alone
> testing qemuarmv5.  And these issues have probably been around for
> months.  Even after getting all of these issues addressed, qemuarmv5
> is still failing testimage.  Honestly, it should be dropped since it's
> not really being used.  If you are only worried about compiling, there
> are other machines in other layers that can be used for this.

The issue with pulseaudio has been discussed on the list and bugs have
been raised upstream. It's due to pulseaudio's switch to meson (ie the
autotools build still correctly detects ARM soft float, although
switching back to the autotools build obviously isn't a good long term
solution).

If you want to drop soft float support in qemuarmv5 or drop the
machine config entirely then there may be valid arguments for doing
that, but a bug in the pulseaudio meson build doesn't seem to be one
of them (since it's completely independent of qemuarmv5).

> > > Signed-off-by: Jon Mason 
> > > Change-Id: I513ed523f03ed091507a099e3f80fa95a6fc7ca9
> >
> > Not sure if there's an official policy for this, but personally I'd
> > say your own private gerrit IDs should be stripped before pushing
> > changes upstream.
>
> These can be dropped if they are problematic.  I haven't heard they
> are forbidden.

I haven't heard they are forbidden either, I was just giving my opinion.

> > > ---
> > >  meta/conf/machine/qemuarmv5.conf | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/meta/conf/machine/qemuarmv5.conf 
> > > b/meta/conf/machine/qemuarmv5.conf
> > > index dfe2a89573b2..29bcc1199ea1 100644
> > > --- a/meta/conf/machine/qemuarmv5.conf
> > > +++ b/meta/conf/machine/qemuarmv5.conf
> > > @@ -18,3 +18,4 @@ PREFERRED_VERSION_linux-yocto ??= "5.10%"
> > >  QB_DTB = 
> > > "${@oe.utils.version_less_or_equal('PREFERRED_VERSION_linux-yocto', 
> > > '4.7', '', 'zImage-versatile-pb.dtb', d)}"
> > >
> > >  KMACHINE_qemuarmv5 = "qemuarm"
> > > +TUNE_CCARGS_MFLOAT = "softfp"
> > > --
> > > 2.20.1
> > >
> > >
> > > 
> > >

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



Re: [OE-core] [PATCH 2/2] core-image-sato: qemuarmv5 doesn't work with >256M RAM

2021-03-10 Thread Andre McCurdy
On Wed, Mar 10, 2021 at 3:04 PM Jon Mason  wrote:
>
> Currently seeing the following error when running runqemu on qemuarmv5:
> runqemu - ERROR - Failed to run qemu: qemu-system-arm: versatilepb: memory 
> size must not exceed 256MB
>
> This is due to the memory size being set to 512 instead of the max
> allowable of 256.  Limit to this and everything is happy.
>
> Signed-off-by: Jon Mason 
> Change-Id: I3339e50a53464b95f52a987ed37868ebf0935b07
> ---
>  meta/recipes-sato/images/core-image-sato.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-sato/images/core-image-sato.bb 
> b/meta/recipes-sato/images/core-image-sato.bb
> index e50b24a47691..8ed8f75e9f92 100644
> --- a/meta/recipes-sato/images/core-image-sato.bb
> +++ b/meta/recipes-sato/images/core-image-sato.bb
> @@ -14,3 +14,4 @@ TOOLCHAIN_HOST_TASK_remove_task-populate-sdk-ext = " 
> nativesdk-intltool nativesd
>
>  QB_MEM = '${@bb.utils.contains("DISTRO_FEATURES", "opengl", "-m 512", "-m 
> 256", d)}'
>  QB_MEM_qemumips = "-m 256"
> +QB_MEM_qemuarmv5 = "-m 256"

Grepping for QB_MEM suggests there are other images which need the
same fix. Maybe good to fix all of them at once rather than one at a
time.

> 2.20.1
>
>
> 
>

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



Re: [OE-core] [PATCH 1/2] qemuarmv5: add softfp

2021-03-10 Thread Andre McCurdy
On Wed, Mar 10, 2021 at 3:04 PM Jon Mason  wrote:
>
> pulseaudio-14.2 is throwing the following error when compiling for
> machine qemuarmv5
> "NEON intrinsics not available with the soft-float ABI.  Please use 
> -mfloat-abi=softfp or -mfloat-abi=hard"
>
> Using softfp to resolve this issue.

Wouldn't "sidestep" be a more accurate description then "resolve" ?

Either way I'm not sure that changing qemuarmv5 just to workaround one
broken package is the right approach. Doesn't it mean OE will no
longer have any test coverage for ARM soft float?

> Signed-off-by: Jon Mason 
> Change-Id: I513ed523f03ed091507a099e3f80fa95a6fc7ca9

Not sure if there's an official policy for this, but personally I'd
say your own private gerrit IDs should be stripped before pushing
changes upstream.

> ---
>  meta/conf/machine/qemuarmv5.conf | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/conf/machine/qemuarmv5.conf 
> b/meta/conf/machine/qemuarmv5.conf
> index dfe2a89573b2..29bcc1199ea1 100644
> --- a/meta/conf/machine/qemuarmv5.conf
> +++ b/meta/conf/machine/qemuarmv5.conf
> @@ -18,3 +18,4 @@ PREFERRED_VERSION_linux-yocto ??= "5.10%"
>  QB_DTB = "${@oe.utils.version_less_or_equal('PREFERRED_VERSION_linux-yocto', 
> '4.7', '', 'zImage-versatile-pb.dtb', d)}"
>
>  KMACHINE_qemuarmv5 = "qemuarm"
> +TUNE_CCARGS_MFLOAT = "softfp"
> --
> 2.20.1
>
>
> 
>

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



Re: [OE-core] [PATCH] resolvconf: add missing dependencies to RDEPENDS

2021-03-09 Thread Andre McCurdy
On Tue, Mar 9, 2021 at 7:23 AM Frans Meulenbroeks
 wrote:
>
> Freaking yahoo email seems to have no option any more to quote decently.
> Guess it is time for a new email provider :-)
> Anyway my response below prefixed with FM:
>
> Op dinsdag 9 maart 2021 00:26:05 CET schreef Khem Raj :
> On 3/8/21 2:25 PM, Andre McCurdy wrote:
> > On Mon, Mar 8, 2021 at 2:15 PM Khem Raj  wrote:
> >>
> >> On 3/8/21 2:11 PM, Andre McCurdy wrote:
> >>> On Mon, Mar 8, 2021 at 11:30 AM Khem Raj  wrote:
> >>>>
> >>>> From: Frans Meulenbroeks 
> >>>>
> >>>> resolvconf uses flock and readlink.
> >>>> So explicitly added dependencies on util-linux (for flock) and coreutils
> >>>> (for readlink).
> >>>> Note that the options used with flock and readlink are not part of the
> >>>> busybox implementations so full-fledged implementations are needed.
> >>>>
> >>>> Signed-off-by: Khem Raj 
> >>>> ---
> >>>>meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb | 2 +-
> >>>>1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb 
> >>>> b/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb
> >>>> index 6df96b699c..6da8cd6023 100644
> >>>> --- a/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb
> >>>> +++ b/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb
> >>>> @@ -9,7 +9,7 @@ LICENSE = "GPLv2+"
> >>>>LIC_FILES_CHKSUM = 
> >>>> "file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b"
> >>>>AUTHOR = "Thomas Hood"
> >>>>HOMEPAGE = "http://packages.debian.org/resolvconf;
> >>>> -RDEPENDS_${PN} = "bash"
> >>>> +RDEPENDS_${PN} = "bash coreutils util-linux"
> >>>
> >>> util-linux-flock has its own package.
> >>
> >> yeah and busybox also provides flock too. Lets drop it
> >
> > Busybox provides flock, but it doesn't support the -w option (wait
> > with timeout). Either the util-linux flock is required or resolvconf
> > needs to be patched to drop the -w option.
>
> right, its to explore possibilities to avoid the deps.
>
> FM: While I am all in favor of avoiding these dependencies, I'm not versed 
> enough in the resolvconf code to judge the impact of dropping -w, so my 
> preference would be to depend on util-linux-flock.

Agreed. Adding a runtime dependency on util-linux-flock is the safest fix.

> >>> Patching resolvconf to use readlink -f (instead of readlink -m) should
> >>> be sufficient to allow it to work with busybox readlink.
>
> FM: this will most likely work. I can make a patch for that, no problem.

For reference, there's a patch which does that here:

  
https://github.com/lgirdk/meta-mng/blob/ofw/recipes-misc/resolvconf/resolvconf/0001-try-to-support-busybox-readlink.patch

> >>>>SRC_URI = 
> >>>> "git://salsa.debian.org/debian/resolvconf.git;protocol=https;branch=unstable
> >>>>  \
> >>>>  file://fix-path-for-busybox.patch \
> >>>> --
> >>>> 2.30.1
>
> On a general note: in the current form the package is broken, so some fix is 
> desirable.

Agreed.

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



Re: [OE-core] [PATCH] resolvconf: add missing dependencies to RDEPENDS

2021-03-08 Thread Andre McCurdy
On Mon, Mar 8, 2021 at 2:15 PM Khem Raj  wrote:
>
> On 3/8/21 2:11 PM, Andre McCurdy wrote:
> > On Mon, Mar 8, 2021 at 11:30 AM Khem Raj  wrote:
> >>
> >> From: Frans Meulenbroeks 
> >>
> >> resolvconf uses flock and readlink.
> >> So explicitly added dependencies on util-linux (for flock) and coreutils
> >> (for readlink).
> >> Note that the options used with flock and readlink are not part of the
> >> busybox implementations so full-fledged implementations are needed.
> >>
> >> Signed-off-by: Khem Raj 
> >> ---
> >>   meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb 
> >> b/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb
> >> index 6df96b699c..6da8cd6023 100644
> >> --- a/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb
> >> +++ b/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb
> >> @@ -9,7 +9,7 @@ LICENSE = "GPLv2+"
> >>   LIC_FILES_CHKSUM = "file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b"
> >>   AUTHOR = "Thomas Hood"
> >>   HOMEPAGE = "http://packages.debian.org/resolvconf;
> >> -RDEPENDS_${PN} = "bash"
> >> +RDEPENDS_${PN} = "bash coreutils util-linux"
> >
> > util-linux-flock has its own package.
>
> yeah and busybox also provides flock too. Lets drop it

Busybox provides flock, but it doesn't support the -w option (wait
with timeout). Either the util-linux flock is required or resolvconf
needs to be patched to drop the -w option.

> > Patching resolvconf to use readlink -f (instead of readlink -m) should
> > be sufficient to allow it to work with busybox readlink.
> >
> >>   SRC_URI = 
> >> "git://salsa.debian.org/debian/resolvconf.git;protocol=https;branch=unstable
> >>  \
> >>  file://fix-path-for-busybox.patch \
> >> --
> >> 2.30.1
> >>
> >>
> >> 
> >>

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



Re: [OE-core] [PATCH] resolvconf: add missing dependencies to RDEPENDS

2021-03-08 Thread Andre McCurdy
On Mon, Mar 8, 2021 at 11:30 AM Khem Raj  wrote:
>
> From: Frans Meulenbroeks 
>
> resolvconf uses flock and readlink.
> So explicitly added dependencies on util-linux (for flock) and coreutils
> (for readlink).
> Note that the options used with flock and readlink are not part of the
> busybox implementations so full-fledged implementations are needed.
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb 
> b/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb
> index 6df96b699c..6da8cd6023 100644
> --- a/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb
> +++ b/meta/recipes-connectivity/resolvconf/resolvconf_1.87.bb
> @@ -9,7 +9,7 @@ LICENSE = "GPLv2+"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b"
>  AUTHOR = "Thomas Hood"
>  HOMEPAGE = "http://packages.debian.org/resolvconf;
> -RDEPENDS_${PN} = "bash"
> +RDEPENDS_${PN} = "bash coreutils util-linux"

util-linux-flock has its own package.

Patching resolvconf to use readlink -f (instead of readlink -m) should
be sufficient to allow it to work with busybox readlink.

>  SRC_URI = 
> "git://salsa.debian.org/debian/resolvconf.git;protocol=https;branch=unstable \
> file://fix-path-for-busybox.patch \
> --
> 2.30.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149126): 
https://lists.openembedded.org/g/openembedded-core/message/149126
Mute This Topic: https://lists.openembedded.org/mt/81183177/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] spirv-tools: Replace strncpy with memcpy

2021-02-27 Thread Andre McCurdy
On Sat, Feb 27, 2021 at 12:18 AM Khem Raj  wrote:
>
> Fixes warnings produced with gcc 11
>
> Signed-off-by: Khem Raj 
> ---
>  .../files/0001-fix-strncpy-bound-error.patch  | 30 +++
>  .../spir/spirv-tools_2020.6.bb|  4 ++-
>  2 files changed, 33 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-graphics/spir/files/0001-fix-strncpy-bound-error.patch
>
> diff --git 
> a/meta/recipes-graphics/spir/files/0001-fix-strncpy-bound-error.patch 
> b/meta/recipes-graphics/spir/files/0001-fix-strncpy-bound-error.patch
> new file mode 100644
> index 00..bc59faa37b
> --- /dev/null
> +++ b/meta/recipes-graphics/spir/files/0001-fix-strncpy-bound-error.patch
> @@ -0,0 +1,30 @@
> +From 1ba007583b83468494c4146bcb7267d863de6a7b Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Fri, 26 Feb 2021 23:54:10 -0800
> +Subject: [PATCH] fix strncpy bound error
> +
> +This patch fixes the following error while using gcc 11
> +error: 'char* __builtin_strncpy(char*, const char*, long unsigned int)' 
> specified bound depends on the length of the source argument 
> [-Werror=stringop-overflow=]
> +
> +Upstream-Status: Submitted 
> [https://github.com/KhronosGroup/SPIRV-Tools/pull/4151]
> +Signed-off-by: Khem Raj 
> +---
> + source/diagnostic.cpp | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/source/diagnostic.cpp b/source/diagnostic.cpp
> +index edc27c8fd..77c29d70c 100644
> +--- a/source/diagnostic.cpp
>  b/source/diagnostic.cpp
> +@@ -37,7 +37,7 @@ spv_diagnostic spvDiagnosticCreate(const spv_position 
> position,
> +   diagnostic->position = *position;
> +   diagnostic->isTextSource = false;
> +   memset(diagnostic->error, 0, length);
> +-  strncpy(diagnostic->error, message, length);
> ++  memcpy(diagnostic->error, message, length);

The memset() should be removed too.

> +   return diagnostic;
> + }
> +
> +--
> +2.30.1
> +
> diff --git a/meta/recipes-graphics/spir/spirv-tools_2020.6.bb 
> b/meta/recipes-graphics/spir/spirv-tools_2020.6.bb
> index 4f45c68bbe..f57a7bd357 100644
> --- a/meta/recipes-graphics/spir/spirv-tools_2020.6.bb
> +++ b/meta/recipes-graphics/spir/spirv-tools_2020.6.bb
> @@ -7,7 +7,9 @@ LICENSE  = "Apache-2.0"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
>
>  SRCREV = "b27b1afd12d05bf238ac7368bb49de73cd620a8e"
> -SRC_URI = "git://github.com/KhronosGroup/SPIRV-Tools.git"
> +SRC_URI = "git://github.com/KhronosGroup/SPIRV-Tools.git \
> +   file://0001-fix-strncpy-bound-error.patch \
> +  "
>  UPSTREAM_CHECK_GITTAGREGEX = "^v(?P\d+(\.\d+)+)$"
>  S = "${WORKDIR}/git"
>
> --
> 2.30.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148722): 
https://lists.openembedded.org/g/openembedded-core/message/148722
Mute This Topic: https://lists.openembedded.org/mt/80947297/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][gatesgarth]Mongodb segfault on gatesgarth

2021-02-23 Thread Andre McCurdy
On Tue, Feb 23, 2021 at 2:39 PM jaewon  wrote:
>
>
> Still struggling with this issue,

Perhaps first decide what you are actually trying to do. The choice is
between including debug symbols in the mongodb binary installed on the
target (e.g. modifying INHIBIT_PACKAGE_STRIP and/or
INHIBIT_PACKAGE_DEBUG_SPLIT) or splitting the debug symbols into a
separate package (ie the default) but then including that package on
the target and trying to have gdb find and use it (e.g. modifying
PACKAGE_DEBUG_SPLIT_STYLE and/or adding mongodb-dbg to IMAGE_INSTALL).
Mixing the two approaches as you seem to be doing probably isn't the
best approach...

Alternatively you can install an unstripped mongodb binary on the
target at run time using "devtool deploy-target". In that case you
might not need to mess with any of the build or packaging related
debug options at all.

> To summarize the steps that I took to see the mongodb segfault issue,
>
>
>
> Here are the steps I took,
>
> Download poky (gatesgarth)
>
> git clone https://git.yoctoproject.org/git/poky -b gatesgarth
>
> openembedded (gatesgarth)
>
> git clone https://github.com/openembedded/meta-openembedded.git -b gatesgarth
>
> Add meta-oe layers to bblayers
>
> Add mongodb to IMAGE_INSTALL
>
>
>
> Build and runqemu  core-image-minimal using qemuarm64
>
> After just these steps I am seeing segfault.
>
>
>
> Anyone know about this issue/what could possibly be the issue?
>
>
>
>
>
>
>
> If not, would also appreciate any pointers on debugging this issues,
>
>
>
> For debugging:
>
>
>
> Added the following to local.conf, (referenced this: 
> https://developer.ridgerun.com/wiki/index.php?title=Preparing_Yocto_Development_Environment_for_Debugging)
>
>
>
> IMAGE_INSTALL_append = " mongodb mongodb-dbg"
>
> EXTRA_IMAGE_FEATURES += " tools-debug"
>
> PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'
>
>
>
> #Specifies to build packages with debugging information
>
> DEBUG_BUILD = "1"
>
> # Do not remove debug symbols
>
> INHIBIT_PACKAGE_STRIP = "1"
>
> # OPTIONAL: Do not split debug symbols in a separate file
>
> INHIBIT_PACKAGE_DEBUG_SPLIT= "1"
>
>
>
> Then using gdb on mongod, I get:
>
> Reading symbols from mongod...
>
> (No debugging symbols found in mongod)
>
>
>
> Noticed nothing is in the -dbg pkgs of mongod,  (without 
> “PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'”, debug files are here: 
> /usr/bin/.debug/mongod, but  /usr/bin/.debug/mongod.debug is where gdb is 
> expecting it, if I copy it as such I get the CRC mismatch issue below)
>
>
>
> Removed the following from the local.conf and added the following to mongod 
> recipe:
>
>
>
> + 120 INHIBIT_PACKAGE_STRIP = "1"
>
> + 121 INHIBIT_PACKAGE_DEBUG_STRIP = "1"
>
> + 122 DEBUG_BUILD = "1"
>
>
>
> Now I see  under mongodb-dbg:
>
> usr/lib/debug/usr/bin/mongod.debug
>
>
>
> but when running gdb I see
>
>
>
> warning: the debug information found in 
> "/usr/lib/debug//usr/bin/mongod.debug" does not match "/usr/bin/mongod" (CRC 
> mismatch).
>
> (No debugging symbols found in mongod)
>
>
>
>
>
> Tried the same experiment in zeus, I get,
>
>
>
> Reading symbols from mongod...
>
>Reading symbols from /usr/bin/.debug/mongod...
>
> BFD: error: /usr/bin/.debug/mongod(.debug_info) is too large (0x4d617681 
> bytes)
>
>
>
> warning: Can't read data for section '.debug_info' in file 
> '/usr/bin/.debug/mongod'
>
> (No debugging symbols found in /usr/bin/.debug/mongod)
>
>
>
> Am I missing something here?
>
> Any pointers would be much appreciated!
>
>
>
> Thanks,
>
> Jaewon
>
>
>
>
>
>
>
> From:  on behalf of "jaewon via 
> lists.openembedded.org" 
> Reply-To: Jaewon Lee 
> Date: Thursday, February 11, 2021 at 6:07 PM
> To: "openembedded-core@lists.openembedded.org" 
> 
> Subject: [OE-core][gatesgarth]Mongodb segfault on gatesgarth
>
>
>
> Hello all,
>
>
>
> Im seeing a segfault running mongod, tested on pure upstream poky and 
> openembedded layers (gatesgarth branch)
>
> Any known issues here on mongod in gatesgarth?
>
>
> Not a perfect test by any means but also tried mongodb version from zeus 
> release where it was working and same issue.
>
> hoping to maybe get some pointers in the right direction to pinpoint issue, 
> also having some trouble setting up debug environment correctly,
>
> Keep getting either ‘no debug symbols found’ or,  ‘the debug info found in 
> /usr/bin/.debug/mongod.debug does not match /usr/bin/mongod (CRC mismatch)’
>
> With what I think are all the correct flags setup to debug..
>
> INHIBIT_PACKAGE_STRIP = "1"
>
> INHIBIT_PACKAGE_DEBUG_STRIP = "1"
>
> INHIBIT_SYSROOT_STRIP = "1"
>
> DEBUG_BUILD = "1"
>
>
>
> PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'
>
> Adding mongodb-dbg,   adding tools-debug
>
>
>
> Any pointers would be much appreciated!
>
>
>
> Thanks,
>
> Jaewon
>
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148527): 
https://lists.openembedded.org/g/openembedded-core/message/148527
Mute This Topic: 

Re: [OE-core] [PATCH] security_flags.inc: Use -O with -D_FORTIFY_SOURCE

2021-02-10 Thread Andre McCurdy
On Wed, Feb 10, 2021 at 12:48 AM Mikko Rapeli  wrote:
>
> Hi,
>
> On Tue, Feb 09, 2021 at 11:37:39PM -0800, Khem Raj wrote:
> > In this case -O  will take effect sadly. and it seems to be that
> > autconf munges the compiler cmdline
> > while generating CFLAGS in generated Makefiles and appends the value
> > of -On coming from CC
> > variable last.
> >
> > I think right solution would be to add same -O as specified in
> > SELECTED_OPTIMIZATION so it remains
> > in sync always, I have sent a patch to ml. Could you test it out and
> > let me know if it works for you as well.
>
> Or let it go? A lot of recipes amend their own optimization flags and override
> distro wide optimization and other compiler flags. I once fixes all recipes
> in a project which were not obeying Os until buildhistory showed change in 
> binary
> sizes... that was a lot of work for a PoC..

If the goal is to ensure that the optimisation flag from
FULL_OPTIMIZATION and the -D_FORTIFY_SOURCE flag from
lcl_maybe_fortify are always applied together then isn't the easiest
solution to move -D_FORTIFY_SOURCE out of lcl_maybe_fortify and into
FULL_OPTIMIZATION ?

Putting a separate optimisation flag in lcl_maybe_fortify and trying
to arrange for it not to clash with or override the one already in
FULL_OPTIMIZATION seems like an ugly solution, even if it can be made
to work.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147922): 
https://lists.openembedded.org/g/openembedded-core/message/147922
Mute This Topic: https://lists.openembedded.org/mt/80425803/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] [RFC] openssl: Enable cryptodev-linux by default

2021-01-29 Thread Andre McCurdy
On Fri, Jan 29, 2021 at 12:45 PM Otavio Salvador
 wrote:
>
> Em sex., 29 de jan. de 2021 às 17:39, Andre McCurdy
>  escreveu:
> >
> > If a distro or BSP layer wants to enable cryptodev-linux support in
> > openssl they can already do so by creating a .bbappend for openssl
> > which adds the PACKAGECONFIG. ie if we decide that the option should
> > be left disabled by default but controllable by the distro or BSP
> > layer then no further changes are required - we already have a fully
> > functional mechanism to do that.
>
> DISTRO yes, BSP is harder. If we enable it, it becomes MACHNE_ARCH as
> well as all packages which depends on it.

That's a concern if you're trying to create a package feed. But in
that case you should already be taking care that BSP layers don't
change the way recipes in common layers are built. ie this is
something you would be controlling from a distro layer anyway.

If you don't care about maintaining a package feed (which I guess is
the majority of us?) then BSP layers which contain .bbappend files for
recipes in common layers works just fine.

> > Going back to the original question of whether cryptodev-linux should
> > be enabled by default, I would say no. It's very much the legacy
> > approach and in the absence of benchmarks to prove otherwise I doubt
> > it gives any advantage in performance on modern platforms (especially
> > CPUs with dedicated crypto instructions).
>
>
> Tom, this is indeed the most important aspect to discuss. We need to
> check if latest openssl with new Linux kernels still require
> cryptodev-linux to use the acceleration.
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147465): 
https://lists.openembedded.org/g/openembedded-core/message/147465
Mute This Topic: https://lists.openembedded.org/mt/80195674/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] [RFC] openssl: Enable cryptodev-linux by default

2021-01-29 Thread Andre McCurdy
On Fri, Jan 29, 2021 at 12:34 AM Diego Santa Cruz via
lists.openembedded.org
 wrote:
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Khem Raj via
> > lists.openembedded.org
> > Sent: 29 January 2021 02:16
> > To: Tom Hochstein ; openembedded-
> > c...@lists.openembedded.org
> > Cc: ota...@ossystems.com.br
> > Subject: Re: [OE-core] [PATCH] [RFC] openssl: Enable cryptodev-linux by
> > default
> >
> >
> >
> > On 1/28/21 1:35 PM, Tom Hochstein wrote:
> > > This is a Request for Comment. Would it be a good idea to enable
> > cryptodev-linux
> > > by default, gaining hardware acceleration where supported? Are there any
> > > unacceptable drawbacks? What happens on hardware without
> > acceleration?
> > >
> >
> > this perhaps helps with devices that include a hardware crypto device
> > but not as much with one;s thats fine but we use qemu machines quite a
> > bit in testing so it would be good to get a readout on qemu secondly, if
> > it does not, then maybe we should see if defining it via
> > MACHINE_FEATUREs might be an option to enable it.
>
> I think that making it a MACHINE_FEATURES would effectively make the task 
> signatures for openssl be machine dependent and that would also make all 
> recipes which depend directly or indirectly on openssl (and there are a lot!) 
> have their task signatures be machine dependent, so they would need to have 
> their PACKAGE_ARCH set to MACHINE_ARCH to avoid triggering spurious rebuilds 
> when switching between machines with and without cryptodev-linux in 
> MACHINE_FEATURES.
>
> So MACHINE_FEATURES does not look like a viable option, a DISTRO_FEATURES 
> might be, although it does not really look like a nice fit either.

MACHINE and DISTRO features are global variables which should be
reserved for configuration decisions which affect multiple recipes (so
that multiple recipes can be configured together under the control of
one option). It doesn't make much sense to create a new MACHINE or
DISTRO feature if it's only going to be used by one recipe.

If a distro or BSP layer wants to enable cryptodev-linux support in
openssl they can already do so by creating a .bbappend for openssl
which adds the PACKAGECONFIG. ie if we decide that the option should
be left disabled by default but controllable by the distro or BSP
layer then no further changes are required - we already have a fully
functional mechanism to do that.

Going back to the original question of whether cryptodev-linux should
be enabled by default, I would say no. It's very much the legacy
approach and in the absence of benchmarks to prove otherwise I doubt
it gives any advantage in performance on modern platforms (especially
CPUs with dedicated crypto instructions).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147463): 
https://lists.openembedded.org/g/openembedded-core/message/147463
Mute This Topic: https://lists.openembedded.org/mt/80195674/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] pulseaudio: define -mfloat-abi=softfp for CC on armv5

2020-12-28 Thread Andre McCurdy
On Mon, Dec 28, 2020 at 6:36 PM Yu, Mingli  wrote:
>
> From: Mingli Yu 
>
> After pulseaudio upgrades from 13.0 to 14.0, it also switches from autotools
> to meson and there's no option for disabling Neon optimizations with meson.
> And the build system adds -mfpu=neon at the end of the compiler command line
> which overrids any earlier -mfpu options and result below build failure:
>
> | 
> /prj/tmp-glibc/work/armv5e-wrs-linux-gnueabi/pulseaudio/14.0-r0/recipe-sysroot-native/usr/lib/arm-wrs-linux-gnueabi/gcc/arm-wrs-linux-gnueabi/10.2.0/include/arm_neon.h:31:2:
>  error: #error "NEON intrinsics not available with the soft-float ABI.  
> Please use -mfloat-abi=softfp or -mfloat-abi=hard"
> |  31 | #error "NEON intrinsics not available with the soft-float ABI.  
> Please use -mfloat-abi=softfp or -mfloat-abi=hard"
>   |  ^
> | ../pulseaudio-14.0/src/pulsecore/mix_neon.c: In function 
> 'pa_mix_ch2_s16ne_neon':
> | ../pulseaudio-14.0/src/pulsecore/mix_neon.c:38:9: error: unknown type name 
> 'int32x4_t'; did you mean 'int32_t'?
> |   38 | int32x4_t sum0, sum1;
>
> Define -mfloat-abi=softfp for CC on armv5 to fix the above issue.

Doesn't look right. That forces the whole package to be compiled with
floating point instructions, which will break targets which need soft
float.

> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
> b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> index e40b8c1c40..44a6a3055e 100644
> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> @@ -123,6 +123,7 @@ PACKAGECONFIG[ipv6] = "-Dipv6=true,-Dipv6=false,"
>  PACKAGECONFIG[manpages] = "-Dman=true,-Dman=false,"
>
>  export TARGET_PFPU = "${TARGET_FPU}"
> +export CC_append_armv5 = " -mfloat-abi=softfp"

Aside from the fact that the change itself looks wrong, what is export
with a conditional append supposed to do? Export unconditionally (and
so have a side effect for targets other than armv5)? Export only if
the conditional append took effect? Since most people have no idea,
it's better to keep export and the conditional append separate.

>  set_cfg_value () {
> sed -i -e "s/\(; *\)\?$2 =.*/$2 = $3/" "$1"
> --
> 2.26.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146290): 
https://lists.openembedded.org/g/openembedded-core/message/146290
Mute This Topic: https://lists.openembedded.org/mt/79283711/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] [yocto-security] [PATCH] openssl: drop support for deprecated algorithms

2020-12-21 Thread Andre McCurdy
On Sat, Dec 19, 2020 at 4:08 PM Richard Purdie
 wrote:
>
> On Sat, 2020-12-19 at 19:04 +0100, Konrad Weihmann wrote:
> >
> > On 19.12.20 18:58, Richard Purdie wrote:
> > > On Sat, 2020-12-19 at 18:53 +0100, Konrad Weihmann wrote:
> > > > On 19.12.20 18:36, Richard Purdie wrote:
> > > > >PACKAGECONFIG[cryptodev-linux] = 
> > > > > "enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux,,cryptodev-module"
> > > > > +PACKAGECONFIG[no-tls1] = "no-tls1"
> > > > > +PACKAGECONFIG[no-tls1_1] = "no-tls1_1"
> > > > >
> > > > >B = "${WORKDIR}/build"
> > > > >do_configure[cleandirs] = "${B}"
> > > > > @@ -52,6 +54,10 @@ EXTRA_OECONF_class-nativesdk = 
> > > > > "--with-rand-seed=os,devrandom"
> > > > >CFLAGS_append_class-native = " -DOPENSSLDIR=/not/builtin 
> > > > > -DENGINESDIR=/not/builtin"
> > > > >CFLAGS_append_class-nativesdk = " -DOPENSSLDIR=/not/builtin 
> > > > > -DENGINESDIR=/not/builtin"
> > > > >
> > > > > +# Disable deprecated crypto algorithms
> > > > > +# Retained for compatibilty - des (curl), dh (python-ssl), dsa (rpm)
> > > > > +DEPRECATED_CRYPTO_FLAGS = " no-ssl no-idea no-psk no-rc2 no-rc4 
> > > > > no-rc5 no-md2 no-md4 no-srp no-camellia no-bf no-mdc2 no-scrypt 
> > > > > no-seed no-siphash no-sm2 no-sm3 no-sm4 no-whirlpool"
> > > > > +
> > > >   From my perspective this breaks backward compatibility, so I would
> > > > rather have them all that as optional PACKAGECONFIG fields (which also
> > > > does make it easier for ppl, still relying on one of those algorithms,
> > > > for whatever reason, to re-enable them) - with the current approach all
> > > > one could do is to override it with a bbappend - and tbh letting ppl
> > > > have bbappends for this recipe, doesn't sound like the best idea in the
> > > > long run to "enforce" any kind of "security" or "hardening"
> > >
> > > Having it as a variable does mean you could customise the variable and
> > > doesn't mean it has to be done with a bbappend, it can be set from a
> > > distro config too.
> > >
> > > I'm not sure turning each one into a packageconfig is going to be more
> > > helpful compared to this in practise...
> >
> > I'm not sure I follow, as this is a "hard" assign - if it would (in
> > theory) a ??= assignment, yes then it would be fine. Still that leaves
> > us with a not commonly known variable, while PACKAGECONFIG is more
> > widely accepted in 3rd party layers/distros from my experience.
>
> You could do various things to this from a distro config, e.g.:
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl = "xxx"
>
> or
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl_ = "xxx"
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl_append = " extra-disable"
>
> DEPRECATED_CRYPTO_FLAGS_pn-openssl_remove = "add-me-back"
>
> so I'd say that its not a particularly "hard" assignment?
>
> We could make it a ??= but I'm not sure it would change much practcial
> use as it would almost always be with an override of some sort?
>
> Whilst PACKAGECONFIG is more well known,the variable name here may
> actually improve readability...

Does it? It just looks like an extension of a definition of
PACKAGECONFIG but with the logic all reversed (e.g. instead of adding
FOO to PACKAGECONFIG to enable support for something we now have to
add no-FOO to the new custom variable to disable something). Inverting
the logic of all the options makes it closer to the semantics expected
by the openssl configure scripts, but makes it further from the
semantics expected by someone using OE to configure a package (who is
presumably used to the "add FOO to PACKAGECONFIG to enable something"
convention).

Converting all these options to individual PACKAGECONFIG options but
not adding them to the default value PACKAGECONFIG seems like the
better approach. Users who need to enable a particular algorithm can
then add it to PACKAGECONFIG in the usual way.

In general, disabling old or unused algorithms by default is a good
change though.

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



Re: [OE-core] [PATCH 3/4] busybox: Run mdev as daemon

2020-12-17 Thread Andre McCurdy
On Thu, Dec 17, 2020 at 7:52 PM Khem Raj  wrote:
>
> On Thu, Dec 17, 2020 at 3:59 PM Andre McCurdy  wrote:
> >
> > On Thu, Dec 17, 2020 at 2:54 PM Khem Raj  wrote:
> > >
> > > When busybox is used for device management, kernel needs to support
> > > older/obsolete mechanism via CONFIG_UEVENT_HELPER and
> > > CONFIG_UEVENT_HELPER_PATH to enable /proc/sys/kernel/hotplug but this
> > > would require kernel defconfig change and will always be needed when
> > > mdev is used, intead run it in daemon mode
> > >
> > > Update mdev init script to run mdev in daemon mode
> > >
> > > Signed-off-by: Khem Raj 
> > > ---
> > >  meta/recipes-core/busybox/busybox/mdev.cfg |  2 +
> > >  meta/recipes-core/busybox/files/mdev   | 56 +++---
> > >  2 files changed, 41 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/meta/recipes-core/busybox/busybox/mdev.cfg 
> > > b/meta/recipes-core/busybox/busybox/mdev.cfg
> > > index 6aefe90e43..143e6097cb 100644
> > > --- a/meta/recipes-core/busybox/busybox/mdev.cfg
> > > +++ b/meta/recipes-core/busybox/busybox/mdev.cfg
> > > @@ -9,3 +9,5 @@ CONFIG_SETSID=y
> > >  CONFIG_CTTYHACK=y
> > >
> > >  CONFIG_FEATURE_SHADOWPASSWDS=y
> > > +CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM=y
> > > +CONFIG_FEATURE_MDEV_DAEMON=y
> > > diff --git a/meta/recipes-core/busybox/files/mdev 
> > > b/meta/recipes-core/busybox/files/mdev
> > > index 8c9c06e96c..2fbdfb073e 100755
> > > --- a/meta/recipes-core/busybox/files/mdev
> > > +++ b/meta/recipes-core/busybox/files/mdev
> > > @@ -1,21 +1,43 @@
> > >  #!/bin/sh
> > > -mount -t proc proc /proc
> > > -mount -t sysfs sysfs /sys
> > > -mount -t tmpfs tmpfs /dev  -o size=64k,mode=0755
> > > -mkdir /dev/pts /dev/shm
> > > -chmod 777 /dev/shm
> > > -mount -t devpts devpts /dev/pts
> > > -touch /dev/mdev.seq
> > > -#sysctl -w kernel.hotplug=/sbin/mdev
> > > -echo "/sbin/mdev" > /proc/sys/kernel/hotplug
> > > -mdev -s
> > > -
> > >  #
> > > -# We might have mounted something over /dev, see if /dev/initctl is 
> > > there.
> > > +# Run the mdev daemon
> > >  #
> > > -if test ! -p /dev/initctl
> > > -then
> > > -rm -f /dev/initctl
> > > -mknod -m 600 /dev/initctl p
> > > -fi
> > > +
> > > +DAEMON="mdev"
> > > +PIDFILE="/var/run/$DAEMON.pid"
> > > +
> > > +
> > > +start() {
> > > +  echo -n "Starting $DAEMON... "
> > > +  start-stop-daemon -S -b -m -p $PIDFILE -x /sbin/mdev -- -df
> >
> > Where do these start-stop-daemon options come from? Using -b for an
> > application which is designed to run as a daemon (and deliberately
> > telling that app to run in the foreground) looks odd, etc.
> >
> > Are there bugs or limitations in mdev which you are trying to workaround?
>
> its using start-stop-daemon applet from busybox which does have these options
> implemented, its so that start-stop-daemon takes the control of the daemon

The question is not whether start-stop-daemon supports using PID files
but whether the busybox mdev application supports creating them.

It looks like although most of the busybox daemons do, mdev does not:

.../busybox-1.32.0 $ grep -r write_pidfile *
debianutils/start_stop_daemon.c:write_pidfile(pidfile);
include/libbb.h:void write_pidfile(const char *path) FAST_FUNC;
include/libbb.h:void write_pidfile_std_path_and_ext(const char *path) FAST_FUNC;
include/libbb.h:#define write_pidfile_std_path_and_ext(path)  ((void)0)
include/libbb.h:#define write_pidfile(path)  ((void)0)
libbb/pidfile.c:void FAST_FUNC write_pidfile(const char *path)
libbb/pidfile.c:void FAST_FUNC write_pidfile_std_path_and_ext(const char *name)
libbb/pidfile.c:write_pidfile(buf);
miscutils/watchdog.c:write_pidfile_std_path_and_ext("watchdog");
miscutils/crond.c:write_pidfile_std_path_and_ext("crond");
networking/ifplugd.c:write_pidfile(pidfile_name);
networking/ntpd.c:write_pidfile_std_path_and_ext("ntpd");
networking/inetd.c:write_pidfile_std_path_and_ext("inetd");
networking/udhcp/dhcpc.c:write_pidfile(client_data.pidfile);
networking/udhcp/dhcpc.c:write_pidfile(client_data.pidfile);
networking/udhcp/dhcpd.c:write_pidfile(server_data.pidfile);
networking/udhcp/d6_dhcpc.c:write_pidfile(client_data.pidfile);
networking/udhcp/d6_dhcpc.c:write_pidfile(client_data.pidfile);
sysklogd/syslogd.c:write_pidfile_std_path_and_ext("syslogd");
sysklogd/klogd.c:write_pidfile_std_path_and_ext("klogd");
util-linux/acpid.c:write_pidfile(opt_pidfile);

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



Re: [OE-core] [PATCH 1/4] initscripts: use quotes for shell variable comparision

2020-12-17 Thread Andre McCurdy
On Thu, Dec 17, 2020 at 3:54 PM Khem Raj  wrote:
>
> On Thu, Dec 17, 2020 at 3:51 PM Andre McCurdy  wrote:
> >
> > On Thu, Dec 17, 2020 at 2:54 PM Khem Raj  wrote:
> > >
> > > Helps to execute it with busybox shell
> >
> > How does it help? Adding quotes would help if $rootcheck is an empty
> > string, but that's not specific to busybox.
> >
> > > Signed-off-by: Khem Raj 
> > > ---
> > >  meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh 
> > > b/meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh
> > > index 02f0351fcb..a63e71b780 100755
> > > --- a/meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh
> > > +++ b/meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh
> > > @@ -74,7 +74,7 @@ test "$VERBOSE" != no && echo "Activating swap"
> > >  #
> > >  # Check the root filesystem.
> > >  #
> > > -if test -f /fastboot || test $rootcheck = no
> > > +if test -f /fastboot || test "$rootcheck" = "no"
> > >  then
> > >test $rootcheck = yes && echo "Fast boot, no filesystem check"
> >
> > Doesn't this instance need to be quoted too?
>
> yes infact there are more cleanup to follow, this series just fixed
> default boot errors on reference images.

Adding quotes around a variable should probably be done consistently,
so maybe it makes sense to hold off on this one until you've finished
the cleanup?

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



Re: [OE-core] [PATCH 3/4] busybox: Run mdev as daemon

2020-12-17 Thread Andre McCurdy
On Thu, Dec 17, 2020 at 2:54 PM Khem Raj  wrote:
>
> When busybox is used for device management, kernel needs to support
> older/obsolete mechanism via CONFIG_UEVENT_HELPER and
> CONFIG_UEVENT_HELPER_PATH to enable /proc/sys/kernel/hotplug but this
> would require kernel defconfig change and will always be needed when
> mdev is used, intead run it in daemon mode
>
> Update mdev init script to run mdev in daemon mode
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-core/busybox/busybox/mdev.cfg |  2 +
>  meta/recipes-core/busybox/files/mdev   | 56 +++---
>  2 files changed, 41 insertions(+), 17 deletions(-)
>
> diff --git a/meta/recipes-core/busybox/busybox/mdev.cfg 
> b/meta/recipes-core/busybox/busybox/mdev.cfg
> index 6aefe90e43..143e6097cb 100644
> --- a/meta/recipes-core/busybox/busybox/mdev.cfg
> +++ b/meta/recipes-core/busybox/busybox/mdev.cfg
> @@ -9,3 +9,5 @@ CONFIG_SETSID=y
>  CONFIG_CTTYHACK=y
>
>  CONFIG_FEATURE_SHADOWPASSWDS=y
> +CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM=y
> +CONFIG_FEATURE_MDEV_DAEMON=y
> diff --git a/meta/recipes-core/busybox/files/mdev 
> b/meta/recipes-core/busybox/files/mdev
> index 8c9c06e96c..2fbdfb073e 100755
> --- a/meta/recipes-core/busybox/files/mdev
> +++ b/meta/recipes-core/busybox/files/mdev
> @@ -1,21 +1,43 @@
>  #!/bin/sh
> -mount -t proc proc /proc
> -mount -t sysfs sysfs /sys
> -mount -t tmpfs tmpfs /dev  -o size=64k,mode=0755
> -mkdir /dev/pts /dev/shm
> -chmod 777 /dev/shm
> -mount -t devpts devpts /dev/pts
> -touch /dev/mdev.seq
> -#sysctl -w kernel.hotplug=/sbin/mdev
> -echo "/sbin/mdev" > /proc/sys/kernel/hotplug
> -mdev -s
> -
>  #
> -# We might have mounted something over /dev, see if /dev/initctl is there.
> +# Run the mdev daemon
>  #
> -if test ! -p /dev/initctl
> -then
> -rm -f /dev/initctl
> -mknod -m 600 /dev/initctl p
> -fi
> +
> +DAEMON="mdev"
> +PIDFILE="/var/run/$DAEMON.pid"
> +
> +
> +start() {
> +  echo -n "Starting $DAEMON... "
> +  start-stop-daemon -S -b -m -p $PIDFILE -x /sbin/mdev -- -df

Where do these start-stop-daemon options come from? Using -b for an
application which is designed to run as a daemon (and deliberately
telling that app to run in the foreground) looks odd, etc.

Are there bugs or limitations in mdev which you are trying to workaround?

> +  [ $? -eq 0 ] && echo "OK" || echo "ERROR"
> +
> +  # coldplug modules
> +  find /sys/ -name modalias -print0 | \
> +xargs -0 sort -u | \
> +tr '\n' '\0' | \
> +xargs -0 modprobe -abq
> +}
> +
> +stop() {
> +  echo -n "Stopping $DAEMON... "
> +  start-stop-daemon -K -p $PIDFILE
> +  [ $? -eq 0 ] && echo "OK" || echo "ERROR"
> +}
> +
> +restart() {
> +  stop
> +  start
> +}
> +
> +case "$1" in
> +  start|stop|restart)
> +  "$1"
> +  ;;
> +  *)
> +  echo "Usage: $0 {start|stop|restart}"
> +  exit 1
> +esac
> +
> +exit $?
>
> --
> 2.29.2
>
>
> 
>

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



Re: [OE-core] [PATCH 1/4] initscripts: use quotes for shell variable comparision

2020-12-17 Thread Andre McCurdy
On Thu, Dec 17, 2020 at 2:54 PM Khem Raj  wrote:
>
> Helps to execute it with busybox shell

How does it help? Adding quotes would help if $rootcheck is an empty
string, but that's not specific to busybox.

> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh 
> b/meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh
> index 02f0351fcb..a63e71b780 100755
> --- a/meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh
> +++ b/meta/recipes-core/initscripts/initscripts-1.0/checkroot.sh
> @@ -74,7 +74,7 @@ test "$VERBOSE" != no && echo "Activating swap"
>  #
>  # Check the root filesystem.
>  #
> -if test -f /fastboot || test $rootcheck = no
> +if test -f /fastboot || test "$rootcheck" = "no"
>  then
>test $rootcheck = yes && echo "Fast boot, no filesystem check"

Doesn't this instance need to be quoted too?

>  else
> --
> 2.29.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145832): 
https://lists.openembedded.org/g/openembedded-core/message/145832
Mute This Topic: https://lists.openembedded.org/mt/79049546/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 5/5] systemd: add RRECOMMENDS for weak dependencies, if enabled

2020-12-11 Thread Andre McCurdy
On Thu, Dec 10, 2020 at 4:53 AM Luca Bocassi  wrote:
>
> From: Luca Boccassi 
>
> Some libraries are now dlopen'ed and skipped at runtime if
> not available. Add them to the RRECOMMENDS list, to allow
> users to exclude them for smaller images even if generally
> enabled at build time.

This seems to imply that these options have some basic level of
functionality even when the corresponding shared library isn't found
at runtime. Is that right?

If there's no functionality at all without the corresponding shared
library then these should just be regular dependencies (and users who
need smaller images should disable via the PACKAGECONFIG rather than
leaving the PACKAGECONFIG enabled but then excluding the shared
library).

Note also that PACKAGECONFIG gives a way to express recommended
dependencies (the 5th argument).

  
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PACKAGECONFIG

> Signed-off-by: Luca Boccassi 
> ---
>  meta/recipes-core/systemd/systemd_247.1.bb | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/meta/recipes-core/systemd/systemd_247.1.bb 
> b/meta/recipes-core/systemd/systemd_247.1.bb
> index f20e86d94b..951bffa23f 100644
> --- a/meta/recipes-core/systemd/systemd_247.1.bb
> +++ b/meta/recipes-core/systemd/systemd_247.1.bb
> @@ -603,6 +603,13 @@ RRECOMMENDS_${PN} += "systemd-extra-utils \
>systemd-conf \
>  "
>
> +# Weak dlopen-style dependencies: if explicitly requested via PACKAGECONFIG, 
> recommend them
> +RRECOMMENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'qrencode', 
> 'qrencode', '', d)} \
> +  ${@bb.utils.contains('PACKAGECONFIG', 'libidn', 
> 'libidn', '', d)} \
> +  ${@bb.utils.contains('PACKAGECONFIG', 'libidn2', 
> 'libidn2', '', d)} \
> +  ${@bb.utils.contains('PACKAGECONFIG', 'cryptsetup', 
> 'cryptsetup', '', d)} \
> +"
> +
>  INSANE_SKIP_${PN} += "dev-so libdir"
>  INSANE_SKIP_${PN}-dbg += "libdir"
>  INSANE_SKIP_${PN}-doc += " libdir"
> --
> 2.29.2
>
>
> 
>

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



Re: [OE-core] [PATCH v2 1/2] iproute2: install tools to mirror install under Debian/Ubuntu

2020-12-09 Thread Andre McCurdy
On Wed, Dec 9, 2020 at 2:39 PM Alan Perry  wrote:
> On 12/7/20 1:49 PM, Richard Purdie wrote:
> > On Sat, 2020-12-05 at 08:22 +, Alan Perry wrote:
> >> Many scripts exist that expect the iproute2 tools to be found in
> >> the same directories where they are found in Debian or Ubuntu.
> >> For the iproute2 tools included in the iproute2 recipe, move
> >> them to those directories or create links there.. Also, add
> >> bash-completion files as is done by Debian and Ubuntu.
> >>
> >> Signed-off-by: Alan Perry 
> >> ---
> >>   .../iproute2/iproute2.inc | 23 +--
> >>   1 file changed, 21 insertions(+), 2 deletions(-)
> > The direction in the patch is worrying me a little.
> >
> > There is a bash-completion class which splits completion files into
> > their own package, most "embedded" users don't want them in the main
> > packages. This patch does something different to what has been done
> > elsewhere.
> >
> > Secondly, I'm also not sure that just because debian does something we
> > should therefore do it, I'm not convinced that scripts should be
> > hardcoding path assumptions about these tools. IF this is such a
> > universal need, why doesn't upstream change the default installation
> > locations? Has it been discussed?
> >
> > I'd expect there to be opinions on this topic but I'm not seeing much
> > discussion. I suspect if if does merge there would be push back later
> > though.
> >
> > Also, the duplication between bin and sbin for ip is not particularly
> > good practise.
> >
> Thanks for your comments. I apologize for the delay in responding, but I
> needed to do some research first.
>
> I will look at the bash-completion class and make the appropriate
> changes there.
>
> As far as the installation path changes, I discussed why those aren't
> the defaults with the iproute2 upstream maintainer. The idea is that the
> upstream puts everything in /sbin and where is appropriate to install
> them for a given distro is left as an exercise for that distro.
>
> The iproute2 recipe is doing that exercise for poky. So, where is the
> correct place to install these tools on poky? I'd argue that they should
> go in the expected directories for Unix-y OSes. Someone at Debian went
> through that analysis and put them where they put them and those mostly
> seem like reasonable places to me. It is also where users coming to
> poky-based systems will likely expecting to find them.
>
> As far as duplicating ip in bin and sbin, I agree that it isn't good
> practice. Having it in both doesn't seem necessary to me.

But isn't that duplication all part of aligning with Debian (where
/sbin/ip is a symlink to /bin/ip)? Presumably something relies on the
symlink or Debian wouldn't be doing it.

Based on:

  https://sources.debian.org/src/iproute2/5.9.0-1/debian/iproute2.install/
  https://sources.debian.org/src/iproute2/5.9.0-1/debian/iproute2.links/

Debian does seem to do quite a lot or rearranging of the installed
files. Open question seems to be whether that rearranging is to align
with requirements which are specific to Debian or something which
other distros might need too?

Based on:

  
https://centos.pkgs.org/8/centos-baseos-x86_64/iproute-5.3.0-5.el8.x86_64.rpm.html

It looks like Centos installs all binaries under /usr/sbin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145437): 
https://lists.openembedded.org/g/openembedded-core/message/145437
Mute This Topic: https://lists.openembedded.org/mt/78730158/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] Automatic cap on BB_NUMBER_THREADS and PARALLEL_MAKE

2020-12-03 Thread Andre McCurdy
On Thu, Dec 3, 2020 at 9:48 AM Ross Burton  wrote:
>
> Hi,
>
> Currently, BB_NUMBER_THREADS and PARALLEL_MAKE use the number of cores
> available unless told otherwise.  This was a good idea six years
> ago[1] but some modern machines are moving to very large core counts.
>
> For example, 88 core dual Xeons are fairly common. A ThunderX2 has 256
> cores (2 sockets, 4 hyperthreads per physical core). The Ampere Altra
> is dual socket 2*80=160 cores.
>
> At this level of parallelisation the sheer amount of I/O from the
> unpack storm is quite excessive.  As a strawman argument, I propose a
> hard cap to the default BB_NUMBER_THREADS of -- and I'm literally
> making up numbers here -- 32.  Maybe 64.  Comments?

Since the default should be the "safe" default (and users wanting or
needing more are expected to profile and tune manually) a cap of 32
sounds reasonable.



> Cheers,
> Ross
>
> [1] 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1529ef0504542145f2b81b2dba4bcc81d5dac96e
>
> 
>

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



Re: [OE-core] [PATCH 1/2] iproute2: install tools to mirror install under Debian/Ubuntu

2020-12-02 Thread Andre McCurdy
On Wed, Dec 2, 2020 at 11:11 AM Alan Perry  wrote:
>
> Many scripts exist that expect the iproute2 tools to be found in
> the same directories where they are found in Debian or Ubuntu.
> For the iproute2 tools included in the iproute2 recipe, move
> them to those directories or create links there. Also, add
> bash-completion files as is done by Debian and Ubuntu.

Rather than creating symlinks etc, could this be done more cleanly by
having "make install" install to the Debian paths directly?

(Presumably Debian isn't manually moving files after "make install",
they are just configuring the build differently).

> Signed-off-by: Alan Perry > ---
>  .../iproute2/iproute2.inc | 21 +--
>  1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-connectivity/iproute2/iproute2.inc 
> b/meta/recipes-connectivity/iproute2/iproute2.inc
> index 403d264308..21f52f80bc 100644
> --- a/meta/recipes-connectivity/iproute2/iproute2.inc
> +++ b/meta/recipes-connectivity/iproute2/iproute2.inc
> @@ -41,6 +41,21 @@ do_install () {
>  install -d ${D}${datadir}
>  mv ${D}/share/* ${D}${datadir}/ || true
>  rm ${D}/share -rf || true
> +
> +install -d ${D}${base_bindir}
> +ln -s /sbin/ip ${D}${base_bindir}/ip
> +mv ${D}${base_sbindir}/ss ${D}${base_bindir}/ss
> +
> +install -d ${D}${bindir}
> +mv ${D}${base_sbindir}/nstat ${D}${bindir}/nstat
> +mv ${D}${base_sbindir}/lnstat ${D}${bindir}/lnstat
> +mv ${D}${base_sbindir}/ctstat ${D}${bindir}/ctstat
> +mv ${D}${base_sbindir}/rtstat ${D}${bindir}/rtstat
> +mv ${D}${base_sbindir}/routef ${D}${bindir}/routef
> +mv ${D}${base_sbindir}/routel ${D}${bindir}/routel
> +
> +install -d ${D}${sbindir}
> +mv ${D}${base_sbindir}/genl ${D}${sbindir}/genl
>  }
>
>  # The .so files in iproute2-tc are modules, not traditional libraries
> @@ -59,7 +74,8 @@ PACKAGES =+ "\
>  "
>
>  FILES_${PN}-tc = "${base_sbindir}/tc* \
> -  ${libdir}/tc/*.so"
> +  ${libdir}/tc/*.so \
> +  ${datadir}/bash-completion/completions/tc"
>  FILES_${PN}-lnstat = "${base_sbindir}/lnstat \
>${base_sbindir}/ctstat \
>${base_sbindir}/rtstat"
> @@ -69,7 +85,8 @@ FILES_${PN}-rtacct = "${base_sbindir}/rtacct"
>  FILES_${PN}-nstat = "${base_sbindir}/nstat"
>  FILES_${PN}-ss = "${base_sbindir}/ss"
>  FILES_${PN}-tipc = "${base_sbindir}/tipc"
> -FILES_${PN}-devlink = "${base_sbindir}/devlink"
> +FILES_${PN}-devlink = "${base_sbindir}/devlink \
> +   ${datadir}/bash-completion/completions/devlink"
>
>  ALTERNATIVE_${PN} = "ip"
>  ALTERNATIVE_TARGET[ip] = "${base_sbindir}/ip.${BPN}"
> --
> 2.17.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145189): 
https://lists.openembedded.org/g/openembedded-core/message/145189
Mute This Topic: https://lists.openembedded.org/mt/78667798/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] libsdl2: Add directfb to PACKAGECONFIG rdepends

2020-11-23 Thread Andre McCurdy
On Mon, Nov 23, 2020 at 11:14 AM Mark Jonas  wrote:
>
> When building libsdl2 with PACKAGECONFIG[directfb] then directfb is
> added to the DEPENDS. But the automatically generated runtime
> dependencies do not add the directfb package to the runtime
> dependencies. Most likely this happens because libsdl2 does not link
> against directfb but uses dlopen() or similar. Thus, the runtime
> dependency to directfb needs to be declared explicitly.
>
> Here, a runtime recommendation is used to allow ignoring the runtime
> dependency using NO_RECOMMENDATIONS.

Why would anyone want to ignore the runtime dependency?

> Signed-off-by: Mark Jonas 
> ---
>  meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb 
> b/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb
> index 2ef7d2e5ef..ae42db2610 100644
> --- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb
> +++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb
> @@ -58,7 +58,7 @@ PACKAGECONFIG ??= " \
>  "
>  PACKAGECONFIG[alsa]   = "--enable-alsa 
> --disable-alsatest,--disable-alsa,alsa-lib,"
>  PACKAGECONFIG[arm-neon]   = "--enable-arm-neon,--disable-arm-neon"
> -PACKAGECONFIG[directfb]   = 
> "--enable-video-directfb,--disable-video-directfb,directfb"
> +PACKAGECONFIG[directfb]   = 
> "--enable-video-directfb,--disable-video-directfb,directfb,,directfb"
>  PACKAGECONFIG[gles2]  = 
> "--enable-video-opengles,--disable-video-opengles,virtual/libgles2"
>  PACKAGECONFIG[jack]   = "--enable-jack,--disable-jack,jack"
>  PACKAGECONFIG[kmsdrm] = 
> "--enable-video-kmsdrm,--disable-video-kmsdrm,libdrm virtual/libgbm"
> --
> 2.25.1
>
>
> 
>

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



Re: [OE-core] [PATCH 2/2] gstreamer1.0-plugins-base: Use bb.utils.filter to reduce code

2020-11-20 Thread Andre McCurdy
On Fri, Nov 20, 2020 at 9:36 AM Otavio Salvador
 wrote:
>
> Signed-off-by: Otavio Salvador 
> ---
>
>  .../gstreamer/gstreamer1.0-plugins-base_1.18.1.bb  | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.18.1.bb 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.18.1.bb
> index 8813b8faca..43d51552f1 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.18.1.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.18.1.bb
> @@ -64,12 +64,7 @@ PACKAGECONFIG[wayland]  = ",,wayland-native wayland 
> wayland-protocols libdrm
>  PACKAGECONFIG[dispmanx] = ",,virtual/libomxil"
>  PACKAGECONFIG[viv-fb]   = ",,virtual/libgles2 virtual/libg2d"
>
> -OPENGL_WINSYS_append = "${@bb.utils.contains('PACKAGECONFIG', 'x11', ' x11', 
> '', d)}"
> -OPENGL_WINSYS_append = "${@bb.utils.contains('PACKAGECONFIG', 'gbm', ' gbm', 
> '', d)}"
> -OPENGL_WINSYS_append = "${@bb.utils.contains('PACKAGECONFIG', 'wayland', ' 
> wayland', '', d)}"
> -OPENGL_WINSYS_append = "${@bb.utils.contains('PACKAGECONFIG', 'dispmanx', ' 
> dispmanx', '', d)}"
> -OPENGL_WINSYS_append = "${@bb.utils.contains('PACKAGECONFIG', 'egl', ' egl', 
> '', d)}"
> -OPENGL_WINSYS_append = "${@bb.utils.contains('PACKAGECONFIG', 'viv-fb', ' 
> viv-fb', '', d)}"
> +OPENGL_WINSYS_append = "${@bb.utils.filter('PACKAGECONFIG', 'x11 gbm wayland 
> dispmanx egl viv-fb', d)}"

This drops the first leading space so isn't exactly equivalent.

>  EXTRA_OEMESON += " \
>  -Ddoc=disabled \
> --
> 2.29.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144882): 
https://lists.openembedded.org/g/openembedded-core/message/144882
Mute This Topic: https://lists.openembedded.org/mt/78394639/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] YPBZ 14125: busybox wget: where to add openssl-bin dependency?

2020-11-20 Thread Andre McCurdy
On Thu, Nov 19, 2020 at 11:11 PM Shachar Menashe  wrote:
>
> I agree that replacing busybox wget with another tool to handle HTTPS is a 
> cleaner solution, I am just a bit worried about backward compatibility...

Breaking backwards compatibility is not generally a big concern for OE
so long as any use cases within oe-core and its test suite are updated
and continue to work.

> If someone used Yocto and relied on HTTPS download functionality (and seeing 
> there are no other suitable tools such as curl that are already supplied with 
> Yocto) then we are breaking that use case

oe-core provides both curl and wget, so alternatives to Busybox wget
are certainly available.

> So the question is whether we break compatibility by removing 
> FEATURE_WGET_HTTPS, or retaining compatibility by including the openssl 
> binary (or doing nothing and retaining the security issue, which personally I 
> think is problematic)
>
> -Original Message-
> From: Andre McCurdy 
> Sent: Thursday, November 19, 2020 9:45 PM
> To: Shachar Menashe 
> Cc: Randy MacLeod ; st...@sakoman.com; Patches 
> and discussions about the oe-core layer 
> 
> Subject: Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin 
> dependency?
>
> [External email: Use caution with links and attachments]
>
> On Wed, Nov 18, 2020 at 10:46 PM Shachar Menashe  wrote:
> >
> > Hi Andre,
> > The way I see it - even if something is declared, it does not mean it
> > is reasonable or even expected I mean - do you earnestly believe that every 
> > Yocto user (or busybox wget user for that matter) read the help text 
> > associated with the config option that their tool is built with?
>
> No, but I expect them to notice the "TLS certificate validation not 
> implemented" warning which Busybox wget outputs.
>
> > From my perspective, they could not care less, they have the prebuilt 
> > binary and they just use it and expect it to work, they have no idea what 
> > config flags were used when building the tool...
> > In the year 2020 it is expected that tools that come pre-shipped with
> > your OS aren't exposed to naïve attacks such as SSL MitM, that can be
> > executed by automated tooling
>
> Trying to be secure by default is a good argument. The solution is probably 
> just to disable FEATURE_WGET_HTTPS though. Users who understand the 
> limitations can enable it manually. Users who want to validate certificates 
> should be guided towards using curl. Having Busybox wget call out to the 
> openssl command line tool is certainly a creative solution, but feels too 
> much like a hack to want to enable by default.
>
> > I think I can back this up with the fact that busybox maintainers
> > chose to integrate our patch that fixes the CVE, and not dismiss it
> >
> > Note that the GNU version of wget is not exposed to this attack, so
> > this furthers the confusion
> >
> > If there are severe technical issues with shipping the openssl
> > executable with Yocto, then we should definitely think about it, but I
> > think this endeavor is worthwhile
> >
> > -Original Message-
> > From: Andre McCurdy 
> > Sent: Thursday, November 19, 2020 3:45 AM
> > To: Randy MacLeod 
> > Cc: Shachar Menashe ; st...@sakoman.com; Patches and
> > discussions about the oe-core layer
> > 
> > Subject: Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin 
> > dependency?
> >
> > [External email: Use caution with links and attachments]
> >
> > On Wed, Nov 18, 2020 at 2:30 PM Randy MacLeod  
> > wrote:
> > >
> > > Hi Shachar,
> > >
> > > On 2020-11-18 1:49 p.m., Shachar Menashe wrote:
> > > > About the busybox patch, I realized that Dunfell doesn't come with
> > > > the "openssl" binary built-in (only the library) but this fix will
> > > > actually requires having the openssl binary (busybox invokes the
> > > > openssl binary directly) Do you think it's reasonable to add it?
> > > > The library is already getting built, so I don't think it's a huge
> > > > deal to add the binary as well
> > >
> > > Hopefully someone opinionated about busybox will make a suggestion
> > > on how to resolve this bug.
> >
> > The meaning of the busybox FEATURE_WGET_HTTPS configure option is made 
> > quite clear in the associated help message. Claiming it's a "severe CVE" is 
> > not correct - it's working as designed.
> >
> >   https://git.busybox.net/busybox/tree/networking/wget.c#n49
> >
> > The behaviour may not be suitable for everyone, but it's th

Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin dependency?

2020-11-19 Thread Andre McCurdy
On Wed, Nov 18, 2020 at 10:46 PM Shachar Menashe  wrote:
>
> Hi Andre,
> The way I see it - even if something is declared, it does not mean it is 
> reasonable or even expected
> I mean - do you earnestly believe that every Yocto user (or busybox wget user 
> for that matter) read the help text associated with the config option that 
> their tool is built with?

No, but I expect them to notice the "TLS certificate validation not
implemented" warning which Busybox wget outputs.

> From my perspective, they could not care less, they have the prebuilt binary 
> and they just use it and expect it to work, they have no idea what config 
> flags were used when building the tool...
> In the year 2020 it is expected that tools that come pre-shipped with your OS 
> aren't exposed to naïve attacks such as SSL MitM, that can be executed by 
> automated tooling

Trying to be secure by default is a good argument. The solution is
probably just to disable FEATURE_WGET_HTTPS though. Users who
understand the limitations can enable it manually. Users who want to
validate certificates should be guided towards using curl. Having
Busybox wget call out to the openssl command line tool is certainly a
creative solution, but feels too much like a hack to want to enable by
default.

> I think I can back this up with the fact that busybox maintainers chose to 
> integrate our patch that fixes the CVE, and not dismiss it
>
> Note that the GNU version of wget is not exposed to this attack, so this 
> furthers the confusion
>
> If there are severe technical issues with shipping the openssl executable 
> with Yocto, then we should definitely think about it, but I think this 
> endeavor is worthwhile
>
> -Original Message-
> From: Andre McCurdy 
> Sent: Thursday, November 19, 2020 3:45 AM
> To: Randy MacLeod 
> Cc: Shachar Menashe ; st...@sakoman.com; Patches and 
> discussions about the oe-core layer 
> Subject: Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin 
> dependency?
>
> [External email: Use caution with links and attachments]
>
> On Wed, Nov 18, 2020 at 2:30 PM Randy MacLeod  
> wrote:
> >
> > Hi Shachar,
> >
> > On 2020-11-18 1:49 p.m., Shachar Menashe wrote:
> > > About the busybox patch, I realized that Dunfell doesn't come with
> > > the "openssl" binary built-in (only the library) but this fix will
> > > actually requires having the openssl binary (busybox invokes the
> > > openssl binary directly) Do you think it's reasonable to add it? The
> > > library is already getting built, so I don't think it's a huge deal
> > > to add the binary as well
> >
> > Hopefully someone opinionated about busybox will make a suggestion on
> > how to resolve this bug.
>
> The meaning of the busybox FEATURE_WGET_HTTPS configure option is made quite 
> clear in the associated help message. Claiming it's a "severe CVE" is not 
> correct - it's working as designed.
>
>   https://git.busybox.net/busybox/tree/networking/wget.c#n49
>
> The behaviour may not be suitable for everyone, but it's the default config 
> we've used for a long time. Users who need a wget which checks certificates 
> should think about installing the full featured version (or try curl if 
> wget's GPLv3 license isn't acceptable).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144833): 
https://lists.openembedded.org/g/openembedded-core/message/144833
Mute This Topic: https://lists.openembedded.org/mt/78352776/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] YPBZ 14125: busybox wget: where to add openssl-bin dependency?

2020-11-18 Thread Andre McCurdy
On Wed, Nov 18, 2020 at 2:30 PM Randy MacLeod
 wrote:
>
> Hi Shachar,
>
> On 2020-11-18 1:49 p.m., Shachar Menashe wrote:
> > About the busybox patch, I realized that Dunfell doesn't come with the 
> > "openssl" binary built-in (only the library) but this fix will actually 
> > requires having the openssl binary (busybox invokes the openssl binary 
> > directly)
> > Do you think it's reasonable to add it? The library is already getting 
> > built, so I don't think it's a huge deal to add the binary as well
>
> Hopefully someone opinionated about busybox will make a suggestion
> on how to resolve this bug.

The meaning of the busybox FEATURE_WGET_HTTPS configure option is made
quite clear in the associated help message. Claiming it's a "severe
CVE" is not correct - it's working as designed.

  https://git.busybox.net/busybox/tree/networking/wget.c#n49

The behaviour may not be suitable for everyone, but it's the default
config we've used for a long time. Users who need a wget which checks
certificates should think about installing the full featured version
(or try curl if wget's GPLv3 license isn't acceptable).

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



Re: [OE-core] [PATCH] webkitgtk: remove '-fno-omit-frame-pointer' for x86

2020-11-10 Thread Andre McCurdy
On Mon, Nov 9, 2020 at 5:53 PM kai  wrote:
>
> On 11/10/20 2:58 AM, Khem Raj wrote:
>
> On Mon, Nov 9, 2020 at 12:18 AM kai  wrote:
>
> On 11/9/20 4:07 PM, Alexander Kanavin wrote:
>
> Right, but then adding _remove to the upstream recipe doesn't seem right - 
> rather you should use _pn-webkitgtk override in your custom config.
>
> I suppose '-fomit-frame-pointer' is common compile flag that other people may 
> also meet this error.
>
> Regards,
> Kai
>
>
> Alex
>
> On Mon, 9 Nov 2020 at 08:52, kai  wrote:
>
> On 11/9/20 3:32 PM, Alexander Kanavin wrote:
>
> This is not seen on the autobuilder, which does world builds on qemux86. 
> Something might be wrong on your side?
>
> Just the option '-fno-omit-frame-pointer' which is not set by default. We 
> have a build with an extra config in local.conf:
>
> SELECTED_OPTIMIZATION = "${PROFILING_OPTIMIZATION}"
>
> which expands to
>
> SELECTED_OPTIMIZATION = "${FULL_OPTIMIZATION} -fno-omit-frame-pointer 
> -fvisibility=default"
>
> then it fails to compile webkitgtk. It could be reproduced with upper config 
> line.
>
> since we do not have global file to control this its fine if you alter
> PROFILING_OPTIMIZATION inside this recipe
> something like PROFILING_OPTIMIZATION_remove = "..."
>-fno-omit-frame-pointer
> OK. I'll follow the snippet such as:
>
> recipes-devtools/binutils/binutils_2.35.bb:SELECTED_OPTIMIZATION_remove_mipsarch
>  = "-O2"

If you want to ensure that something is built without frame pointers
then appending "-fomit-frame-pointer" is clearer (and more robust)
than trying to remove "-fno-omit-frame-pointer".

> Thanks,
> Kai
>
>
>
> Regards,
> Kai
>
>
>
>
> Alex
>
> On Mon, 9 Nov 2020 at 01:32, kai  wrote:
>
> From: Kai Kang 
>
> It fails to compile webkitgtk for qemux86 if compile option
> '-fno-omit-frame-pointer' is applied:
>
> | 
> TOPDIR/tmp-glibc/work/core2-32-wrsmllib32-linux/lib32-webkitgtk/2.30.1-r0/webkitgtk-2.30.1/
> Source/JavaScriptCore/runtime/JSFinalizationRegistry.cpp:47:1:
> | internal compiler error: in find_oldest_value_reg, at regcprop.c:438
> |47 | }
>
> Signed-off-by: Kai Kang 
> ---
>  meta/recipes-sato/webkit/webkitgtk_2.30.2.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.30.2.bb 
> b/meta/recipes-sato/webkit/webkitgtk_2.30.2.bb
> index 1acba6be1d..11fdb59034 100644
> --- a/meta/recipes-sato/webkit/webkitgtk_2.30.2.bb
> +++ b/meta/recipes-sato/webkit/webkitgtk_2.30.2.bb
> @@ -79,6 +79,7 @@ EXTRA_OECMAKE_append_arc = " -DENABLE_JIT=OFF "
>  # which is not enough for binaries larger than 32 MiB
>  CFLAGS_append_arc = " -mlong-calls"
>  CXXFLAGS_append_arc = " -mlong-calls"
> +CXXFLAGS_remove_x86 = "-fno-omit-frame-pointer"
>
>  # Javascript JIT is not supported on powerpc
>  EXTRA_OECMAKE_append_powerpc = " -DENABLE_JIT=OFF "
> --
> 2.17.1
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144455): 
https://lists.openembedded.org/g/openembedded-core/message/144455
Mute This Topic: https://lists.openembedded.org/mt/78125973/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] bison: remove the parallel build patch

2020-09-14 Thread Andre McCurdy
On Mon, Sep 14, 2020 at 1:35 AM Yu, Mingli  wrote:
>
> From: Mingli Yu 
>
> Remove the parallel build patch as the issue have already been
> fixed in bison 3.7.2(f7b642cf build: fix incorrect dependencies).

If parallel make issues have been fixed upstream then this workaround
should be removed from the recipe too:

 # Reset any loadavg set via environment, it breaks parallel build
 # | ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error:
uniwidth.h: No such file or directory
 # |  #include "uniwidth.h"
 # |   ^~~~
 EXTRA_OEMAKE_append = " -l"

> Signed-off-by: Mingli Yu 
> ---
>  .../0001-bison-fix-the-parallel-build.patch   | 63 ---
>  meta/recipes-devtools/bison/bison_3.7.2.bb|  1 -
>  2 files changed, 64 deletions(-)
>  delete mode 100644 
> meta/recipes-devtools/bison/bison/0001-bison-fix-the-parallel-build.patch
>
> diff --git 
> a/meta/recipes-devtools/bison/bison/0001-bison-fix-the-parallel-build.patch 
> b/meta/recipes-devtools/bison/bison/0001-bison-fix-the-parallel-build.patch
> deleted file mode 100644
> index c3be91a109..00
> --- 
> a/meta/recipes-devtools/bison/bison/0001-bison-fix-the-parallel-build.patch
> +++ /dev/null
> @@ -1,63 +0,0 @@
> -From e0dbcee6e25b3c0cb11a627bbfe3af45ef67ec30 Mon Sep 17 00:00:00 2001
> -From: Mingli Yu 
> -Date: Thu, 14 May 2020 15:23:16 +0800
> -Subject: [PATCH] bison: fix the parallel build
> -
> -Explicitly make the BUILT_SOURCES which
> -are the generated headers such as stdio.h,
> -fcntl.h and etc to be the dependencies of
> -the gl_LIBOBJS such as libbison_a-sprintf.o,
> -libbison_a-printf.o and etc to guarantee the
> -BUILT_SOURCES is generated before begin to
> -compile EXTRA_lib_libbison_a_SOURCES such as
> -fprintf.c in parallel builid, otherwise there
> -may come below error:
> - | muscle-tab.c:(.text+0x77a): undefined reference to `rpl_sprintf'
> -
> -It does the same for src_bison_OBJECTS and
> -lib_libbison_a_OBJECTS to make sure BUILT_SOURCES
> -generated before begin to compile src_bison_SOURCES
> -which contains AnnotationList.c and etc.
> -
> -BTW, the MOSTLYCLEANFILES also contains the
> -generated header needs to be created early
> -in the build process, so add it also in to
> -avoid below error:
> - | ./lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: No such file or 
> directory
> -
> -Upstream-Status: Submitted [bison-patc...@gnu.org maillist]
> -
> -Signed-off-by: Mingli Yu 
> 
> - lib/gnulib.mk | 2 ++
> - src/local.mk  | 1 +
> - 2 files changed, 3 insertions(+)
> -
> -diff --git a/lib/gnulib.mk b/lib/gnulib.mk
> -index c21c656..27fb3dc 100644
>  a/lib/gnulib.mk
> -+++ b/lib/gnulib.mk
> -@@ -120,6 +120,8 @@ lib_libbison_a_SOURCES =
> - lib_libbison_a_LIBADD = $(gl_LIBOBJS)
> - lib_libbison_a_DEPENDENCIES = $(gl_LIBOBJS)
> - EXTRA_lib_libbison_a_SOURCES =
> -+$(lib_libbison_a_OBJECTS): $(BUILT_SOURCES) $(MOSTLYCLEANFILES:%.h)
> -+$(gl_LIBOBJS): $(BUILT_SOURCES) $(MOSTLYCLEANFILES:%.h)
> -
> - lib_libbison_a_CPPFLAGS = $(AM_CPPFLAGS) 
> -DDEFAULT_TEXT_DOMAIN=\"bison-gnulib\"
> -
> -diff --git a/src/local.mk b/src/local.mk
> -index 61dc573..b5b9079 100644
>  a/src/local.mk
> -+++ b/src/local.mk
> -@@ -24,6 +24,7 @@ if RELOCATABLE_VIA_LD
> -   src_bison_LDFLAGS = `$(RELOCATABLE_LDFLAGS) $(bindir)`
> - endif
> -
> -+$(src_bison_OBJECTS): $(BUILT_SOURCES) $(MOSTLYCLEANFILES:%.h)
> - src_bison_CFLAGS = $(AM_CFLAGS) $(WERROR_CFLAGS)
> - src_bison_SOURCES = \
> -   src/AnnotationList.c  \
> ---
> -2.17.1
> -
> diff --git a/meta/recipes-devtools/bison/bison_3.7.2.bb 
> b/meta/recipes-devtools/bison/bison_3.7.2.bb
> index f7bf70fff3..efc426376d 100644
> --- a/meta/recipes-devtools/bison/bison_3.7.2.bb
> +++ b/meta/recipes-devtools/bison/bison_3.7.2.bb
> @@ -11,7 +11,6 @@ DEPENDS = "bison-native flex-native"
>
>  SRC_URI = "${GNU_MIRROR}/bison/bison-${PV}.tar.xz \
> file://add-with-bisonlocaledir.patch \
> -   file://0001-bison-fix-the-parallel-build.patch \
> "
>  SRC_URI[sha256sum] = 
> "7948d193104d979c0fb0294a1854c73c89d72ae41acfc081826142578a78a91b"
>
> --
> 2.17.1
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#142546): 
https://lists.openembedded.org/g/openembedded-core/message/142546
Mute This Topic: https://lists.openembedded.org/mt/76837897/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] squashfs-tools: Allow COMP_DEFAULT to be changed easily at build time

2020-09-14 Thread Andre McCurdy
On Mon, Sep 14, 2020 at 2:59 AM Peter Morrow
 wrote:
>
> The default compression algorithm is currently gzip, this patch allows the
> default to be changed by setting SQUASHFS_TOOLS_COMP_DEFAULT to a valid
> compression algorithm.
>
> Signed-off-by: Peter Morrow 
> ---
>  meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb 
> b/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
> index b06951d..42fae28 100644
> --- a/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
> +++ b/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
> @@ -25,6 +25,9 @@ PACKAGECONFIG[xattr] = 
> "XATTR_SUPPORT=1,XATTR_SUPPORT=0,attr"
>  PACKAGECONFIG[zstd] = "ZSTD_SUPPORT=1,ZSTD_SUPPORT=0,zstd"
>  PACKAGECONFIG[reproducible] = 
> "REPRODUCIBLE_DEFAULT=1,REPRODUCIBLE_DEFAULT=0,"
>
> +SQUASHFS_TOOLS_COMP_DEFAULT ?= "gzip"
> +EXTRA_OEMAKE += "COMP_DEFAULT=${SQUASHFS_TOOLS_COMP_DEFAULT}"

Since you can easily override COMP_DEFAULT by setting EXTRA_OEMAKE
from a .bbappend, I don't think it's necessary to add this to the main
recipe.

>  do_compile() {
> oe_runmake all
>  }
> --
> 1.8.3.1
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#142545): 
https://lists.openembedded.org/g/openembedded-core/message/142545
Mute This Topic: https://lists.openembedded.org/mt/76838796/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] sysvinit: Remove ${B} assignment

2020-09-12 Thread Andre McCurdy
On Sat, Sep 12, 2020 at 12:46 PM Michael Gloff  wrote:
>
> On Sat, Sep 12, 2020 at 2:11 PM Richard Purdie 
>  wrote:
>>
>> On Sat, 2020-09-12 at 11:48 -0500, Michael Gloff wrote:
>> > In order for the VERSION variable to be set, the
>> > top level Makefile should be used, which only
>> > builds the code in /src anyway.
>> >
>> > Signed-off-by: Michael Gloff 
>> > ---
>> >  meta/recipes-core/sysvinit/sysvinit_2.97.bb | 1 -
>> >  1 file changed, 1 deletion(-)
>> >
>> > diff --git a/meta/recipes-core/sysvinit/sysvinit_2.97.bb
>> > b/meta/recipes-core/sysvinit/sysvinit_2.97.bb
>> > index 80ab9d70e7..98916f7f19 100644
>> > --- a/meta/recipes-core/sysvinit/sysvinit_2.97.bb
>> > +++ b/meta/recipes-core/sysvinit/sysvinit_2.97.bb
>> > @@ -24,7 +24,6 @@ SRC_URI =
>> > "${SAVANNAH_GNU_MIRROR}/sysvinit/sysvinit-${PV}.tar.xz \
>> >  SRC_URI[sha256sum] =
>> > "2d5996857519bfd8634d2e1debabb3238fb38440f65fbfdc46420ee8bdf25110"
>> >
>> >  S = "${WORKDIR}/sysvinit-${PV}"
>> > -B = "${S}/src"
>> >
>> >  inherit update-alternatives features_check
>> >  DEPENDS_append = " update-rc.d-native base-passwd virtual/crypt"
>>
>> I don't understand what you're saying. Why do we need the VERSION
>> variable to be set? Does sysvinit not support a separate build
>> directory?
>>
>> Can you rewrite the commit message so that someone who hasn't looked at
>> the code can understand what the problem is we're fixing, why its a
>> problem and why this is the correct solution.
>>
>> Thanks!
>>
>> Richard
>
> This issue is seeing no version on boot up since the switch from 2.88:
> INIT: version  booting
> instead of:
> INIT: version 2.96 booting
> with this change.
>
> The VERSION variable that is used for all of the binaries of sysvinit is 
> defined in the top level Makefile.
>
> VERSION=$(shell sed -rn '1s/.*[[:blank:]]\((.*)\)[[:blank:]].*/\1/p' 
> doc/Changelog)
>
> I'm not sure about the separate build directory. Any tips?
> Thanks,

A separate build directory typically only applies for components which
build with autotools, cmake, etc. For components such as this one
which build with handwritten Makefiles the default is to build in the
source directory.

Anyway, the patch looks fine. Key point is that you want to run make
in the top level source directory rather than the "src" subdirectory
to ensure that variables set by the top level Makefile are correctly
defined.

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

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


Re: [OE-core] [PATCH v2] squashfs-tools: Allow COMP_DEFAULT to be changed easily at build time

2020-09-12 Thread Andre McCurdy
On Fri, Sep 11, 2020 at 10:04 PM Khem Raj  wrote:
>
>
>
> On 9/11/20 10:33 AM, Andre McCurdy wrote:
> > On Fri, Sep 11, 2020 at 10:21 AM Peter Morrow
> >  wrote:
> >>
> >> The default compression algorithm is gzip, this patch allows the default
> >> to be changed via a bbappend file by setting SQUASHFS_TOOLS_COMP_DEFAULT
> >> to a valid compression algorithm.
> >>
> >> Signed-off-by: Peter Morrow 
> >> ---
> >>  ...ols-Allow-COMP_DEFAULT-to-be-overridden-v.patch | 34 
> >> ++
> >>  .../squashfs-tools/squashfs-tools_git.bb   |  4 +++
> >>  2 files changed, 38 insertions(+)
> >>  create mode 100644 
> >> meta/recipes-devtools/squashfs-tools/files/0001-squashfs-tools-Allow-COMP_DEFAULT-to-be-overridden-v.patch
> >>
> >> diff --git 
> >> a/meta/recipes-devtools/squashfs-tools/files/0001-squashfs-tools-Allow-COMP_DEFAULT-to-be-overridden-v.patch
> >>  
> >> b/meta/recipes-devtools/squashfs-tools/files/0001-squashfs-tools-Allow-COMP_DEFAULT-to-be-overridden-v.patch
> >> new file mode 100644
> >> index 000..5f12c42
> >> --- /dev/null
> >> +++ 
> >> b/meta/recipes-devtools/squashfs-tools/files/0001-squashfs-tools-Allow-COMP_DEFAULT-to-be-overridden-v.patch
> >> @@ -0,0 +1,34 @@
> >> +From d2d9b517696f5950597f5b60ae8fdade5b7c14a9 Mon Sep 17 00:00:00 2001
> >> +From: Peter Morrow 
> >> +Date: Fri, 4 Sep 2020 15:43:15 +0100
> >> +Subject: [PATCH] squashfs-tools: Allow COMP_DEFAULT to be overridden via 
> >> make
> >> + cmdline
> >> +
> >> +Currently the only way to modify the default compression algorithm is to
> >> +modify the Makefile. It is useful to be able to set the default 
> >> compression
> >> +algorithm via the make command line since otherwise a build time search
> >> +replace operation needs to be performed on the Makefile.
> >
> > That's not how Makefiles normally work. Options set via the command
> > line over-ride variables set with = in the Makefile.
> >
> > Does setting your chosen value for COMP_DEFAULT on the make command
> > line really not work?
>
> that works if make is invoked with -e option, We do not use make -e with
> bare makefile based recipes.

The -e option is related to environment variables. It's not relevant
for this discussion - which is about setting options via the make
command line.

> >> +Upstream-Status: Submitted 
> >> [https://github.com/plougher/squashfs-tools/pull/93 ]
> >> +
> >> +Signed-off-by: Peter Morrow 
> >> +---
> >> + squashfs-tools/Makefile | 2 +-
> >> + 1 file changed, 1 insertion(+), 1 deletion(-)
> >> +
> >> +diff --git a/squashfs-tools/Makefile b/squashfs-tools/Makefile
> >> +index aee4b96..7425605 100644
> >> +--- a/squashfs-tools/Makefile
> >>  b/squashfs-tools/Makefile
> >> +@@ -85,7 +85,7 @@ GZIP_SUPPORT = 1
> >> + # in Mksquashfs.  Obviously the compression algorithm must have been
> >> + # selected to be built
> >> + #
> >> +-COMP_DEFAULT = gzip
> >> ++COMP_DEFAULT ?= gzip
> >> +
> >> +
> >> + ###
> >> +--
> >> +2.20.1
> >> +
> >> diff --git a/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb 
> >> b/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
> >> index b06951d..df025d4 100644
> >> --- a/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
> >> +++ b/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
> >> @@ -9,6 +9,7 @@ PV = "4.4"
> >>  SRCREV = "52eb4c279cd283ed9802dd1ceb686560b22ffb67"
> >>  SRC_URI = "git://github.com/plougher/squashfs-tools.git;protocol=https \
> >> 
> >> file://0001-squashfs-tools-fix-build-failure-against-gcc-10.patch;striplevel=2
> >>  \
> >> +   
> >> file://0001-squashfs-tools-Allow-COMP_DEFAULT-to-be-overridden-v.patch;striplevel=2
> >>  \
> >>  "
> >>
> >>  S = "${WORKDIR}/git/squashfs-tools"
> >> @@ -25,6 +26,9 @@ PACKAGECONFIG[xattr] = 
> >> "XATTR_SUPPORT=1,XATTR_SUPPORT=0,attr"
> >>  PACKAGECONFIG[zstd] = "ZSTD_SUPPORT=1,ZSTD_SUPPORT=0,zstd"
> >>  PACKAGECONFIG[reproducible] = 
> >> "REPRODUCIBLE_DEFAULT=1,REPRODUCIBLE_DEFAULT=0,"
> >>
> >> +SQUASHFS_TOOLS_COMP_DEFAULT ?= "gzip"
> >> +EXTRA_OEMAKE += "COMP_DEFAULT=${SQUASHFS_TOOLS_COMP_DEFAULT}"
> >
> > Note that this will force the recipe's default value even if upstream
> > squashfs-tools changes. Not a problem now as the two are the same, but
> > something which will need to be checked each time squashfs-tools is
> > updated.
> >
> >>  do_compile() {
> >> oe_runmake all
> >>  }
> >> --
> >> 1.8.3.1
> >>
> >>
> >>
> >> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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


Re: [OE-core] [PATCH v2] squashfs-tools: Allow COMP_DEFAULT to be changed easily at build time

2020-09-11 Thread Andre McCurdy
On Fri, Sep 11, 2020 at 10:21 AM Peter Morrow
 wrote:
>
> The default compression algorithm is gzip, this patch allows the default
> to be changed via a bbappend file by setting SQUASHFS_TOOLS_COMP_DEFAULT
> to a valid compression algorithm.
>
> Signed-off-by: Peter Morrow 
> ---
>  ...ols-Allow-COMP_DEFAULT-to-be-overridden-v.patch | 34 
> ++
>  .../squashfs-tools/squashfs-tools_git.bb   |  4 +++
>  2 files changed, 38 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/squashfs-tools/files/0001-squashfs-tools-Allow-COMP_DEFAULT-to-be-overridden-v.patch
>
> diff --git 
> a/meta/recipes-devtools/squashfs-tools/files/0001-squashfs-tools-Allow-COMP_DEFAULT-to-be-overridden-v.patch
>  
> b/meta/recipes-devtools/squashfs-tools/files/0001-squashfs-tools-Allow-COMP_DEFAULT-to-be-overridden-v.patch
> new file mode 100644
> index 000..5f12c42
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/squashfs-tools/files/0001-squashfs-tools-Allow-COMP_DEFAULT-to-be-overridden-v.patch
> @@ -0,0 +1,34 @@
> +From d2d9b517696f5950597f5b60ae8fdade5b7c14a9 Mon Sep 17 00:00:00 2001
> +From: Peter Morrow 
> +Date: Fri, 4 Sep 2020 15:43:15 +0100
> +Subject: [PATCH] squashfs-tools: Allow COMP_DEFAULT to be overridden via make
> + cmdline
> +
> +Currently the only way to modify the default compression algorithm is to
> +modify the Makefile. It is useful to be able to set the default compression
> +algorithm via the make command line since otherwise a build time search
> +replace operation needs to be performed on the Makefile.

That's not how Makefiles normally work. Options set via the command
line over-ride variables set with = in the Makefile.

Does setting your chosen value for COMP_DEFAULT on the make command
line really not work?

> +Upstream-Status: Submitted 
> [https://github.com/plougher/squashfs-tools/pull/93 ]
> +
> +Signed-off-by: Peter Morrow 
> +---
> + squashfs-tools/Makefile | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/squashfs-tools/Makefile b/squashfs-tools/Makefile
> +index aee4b96..7425605 100644
> +--- a/squashfs-tools/Makefile
>  b/squashfs-tools/Makefile
> +@@ -85,7 +85,7 @@ GZIP_SUPPORT = 1
> + # in Mksquashfs.  Obviously the compression algorithm must have been
> + # selected to be built
> + #
> +-COMP_DEFAULT = gzip
> ++COMP_DEFAULT ?= gzip
> +
> +
> + ###
> +--
> +2.20.1
> +
> diff --git a/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb 
> b/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
> index b06951d..df025d4 100644
> --- a/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
> +++ b/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
> @@ -9,6 +9,7 @@ PV = "4.4"
>  SRCREV = "52eb4c279cd283ed9802dd1ceb686560b22ffb67"
>  SRC_URI = "git://github.com/plougher/squashfs-tools.git;protocol=https \
> 
> file://0001-squashfs-tools-fix-build-failure-against-gcc-10.patch;striplevel=2
>  \
> +   
> file://0001-squashfs-tools-Allow-COMP_DEFAULT-to-be-overridden-v.patch;striplevel=2
>  \
>  "
>
>  S = "${WORKDIR}/git/squashfs-tools"
> @@ -25,6 +26,9 @@ PACKAGECONFIG[xattr] = 
> "XATTR_SUPPORT=1,XATTR_SUPPORT=0,attr"
>  PACKAGECONFIG[zstd] = "ZSTD_SUPPORT=1,ZSTD_SUPPORT=0,zstd"
>  PACKAGECONFIG[reproducible] = 
> "REPRODUCIBLE_DEFAULT=1,REPRODUCIBLE_DEFAULT=0,"
>
> +SQUASHFS_TOOLS_COMP_DEFAULT ?= "gzip"
> +EXTRA_OEMAKE += "COMP_DEFAULT=${SQUASHFS_TOOLS_COMP_DEFAULT}"

Note that this will force the recipe's default value even if upstream
squashfs-tools changes. Not a problem now as the two are the same, but
something which will need to be checked each time squashfs-tools is
updated.

>  do_compile() {
> oe_runmake all
>  }
> --
> 1.8.3.1
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#142443): 
https://lists.openembedded.org/g/openembedded-core/message/142443
Mute This Topic: https://lists.openembedded.org/mt/76784587/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] asio: extend recipe to add native support

2020-08-20 Thread Andre McCurdy
On Thu, Aug 20, 2020 at 8:51 AM Bjarne Michelsen via
lists.openembedded.org
 wrote:
>
> Allows usage of asio for native packages

Comment should explain why.

> Signed-off-by: Bjarne Michelsen 
> ---
>  meta-oe/recipes-support/asio/asio_1.16.1.bb | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta-oe/recipes-support/asio/asio_1.16.1.bb 
> b/meta-oe/recipes-support/asio/asio_1.16.1.bb
> index f381d12fb..dfc3b798d 100644
> --- a/meta-oe/recipes-support/asio/asio_1.16.1.bb
> +++ b/meta-oe/recipes-support/asio/asio_1.16.1.bb
> @@ -25,3 +25,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/asio/${BP}.tar.bz2"
>  PACKAGECONFIG ??= "boost"
>
>  PACKAGECONFIG[boost] = "--with-boost,--without-boost,boost"
> +
> +BBCLASSEXTEND += "native nativesdk"

By convention BBCLASSEXTEND should go at the end of the recipe and
assignment should be = rather than +=.

> +
> +EXTRA_OECONF_class-native += "--with-boost=${STAGING_LIBDIR_NATIVE}"

Don't use += with an override. It doesn't do what you expect.

If you want to append to a variable under the control of an override
then use _append.

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

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


Re: [OE-core] [dunfell] [PATCH] cmake-native: Use cmake-provided zstd library; supported host distro zstd may be too old.

2020-08-19 Thread Andre McCurdy
On Wed, Aug 19, 2020 at 1:49 PM Leon Woestenberg  wrote:
>
> Hello Adrian, all,
>
> On Sat, Aug 15, 2020 at 9:55 AM Adrian Bunk  wrote:
>>
>> On Fri, Aug 14, 2020 at 11:44:17PM +0200, Alexander Kanavin wrote:
>> > This needs to go to master first probably?
>>
>> Better for master might be moving zstd from meta-openembedded,
>> and then DEPENDS on zstd-native?
>>
>> IMHO moving target zstd to OE-core is already overdue,
>> so this would not be solely for cmake.
>>
>
> Good point, makes better sense then my proposed fix for cmake-native only.
>
> More breakage of master against Ubuntu 16.04 (still supported by Yocto) that 
> supports Adrian's suggestion:

If cmake-native is auto detecting zstd support from the host (and
therefore building non-deterministically depending on whether or not
the host has zstd development libraries) then the build breakage is
just a symptom. Adding zstd to oe-core would be a good approach to
fixing the bug for master but not for older releases.

>
> | 
> ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c: 
> In function ‘int lto_normalized_zstd_level()’:
> | 
> ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c:120:36:
>  error: ‘ZSTD_maxCLevel’ was not declared in this scope
> |else if (level > ZSTD_maxCLevel ())
> | ^
> | 
> ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c: 
> In function ‘void lto_uncompression_zstd(lto_compression_stream*)’:
> | 
> ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c:160:74:
>  error: ‘ZSTD_getFrameContentSize’ was not declared in this scope
> |unsigned long long const rsize = ZSTD_getFrameContentSize (cursor, size);
> |   ^
> | 
> ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c:161:16:
>  error: ‘ZSTD_CONTENTSIZE_ERROR’ was not declared in this scope
> |if (rsize == ZSTD_CONTENTSIZE_ERROR)
> | ^
> | 
> ../../../../../../../work-shared/gcc-10.2.0-r0/gcc-10.2.0/gcc/lto-compress.c:163:21:
>  error: ‘ZSTD_CONTENTSIZE_UNKNOWN’ was not declared in this scope
> |else if (rsize == ZSTD_CONTENTSIZE_UNKNOWN)
> |  ^
> | Makefile:1118: recipe for target 'lto-compress.o' failed
> | make[1]: *** [lto-compress.o] Error 1
> | make[1]: *** Waiting for unfinished jobs
>
> Did not deep-dive into this, nor test with Adrian's suggestion yet.
>
> Regards,
>
> Leon.
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141647): 
https://lists.openembedded.org/g/openembedded-core/message/141647
Mute This Topic: https://lists.openembedded.org/mt/76196110/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] Why disable NEON support in recipes if runtime detection works?

2020-07-29 Thread Andre McCurdy
On Wed, Jul 29, 2020 at 6:46 AM Tanu Kaskinen  wrote:
>
> On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote:
> > On Sun, Jul 26, 2020 at 7:01 AM Khem Raj  wrote:
> > > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen  wrote:
> > > > On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote:
> > > > > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote:
> > > > > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen  wrote:
> > > > > > > Hi!
> > > > > > >
> > > > > > > If a recipe provides NEON optimizations, should those be 
> > > > > > > explicitly
> > > > > > > disabled when "neon" is not in TUNE_FEATUERS, even if the 
> > > > > > > software is
> > > > > > > able to detect NEON availability at runtime?
> > > > > > >
> > > > > > > I'm currently converting the pulseaudio recipe from Autotools to 
> > > > > > > Meson,
> > > > > > > and the old Autotools build system supports disabling NEON
> > > > > > > optimizations but the Meson build system doesn't. So I'm 
> > > > > > > wondering if I
> > > > > > > should add the missing feature to the Meson build system, or just 
> > > > > > > let
> > > > > > > the runtime detection do its work.
> > > > > > >
> > > > > > > Is there ever need for disabling NEON optimizations if the CPU
> > > > > > > indicates NEON support? I guess it could be useful for testing 
> > > > > > > the "no
> > > > > > > NEON" case (I today found out that dropping "neon" from 
> > > > > > > TUNE_FEATURES
> > > > > > > doesn't remove NEON support from the qemuarm machine), but 
> > > > > > > otherwise it
> > > > > > > seems unnecessary, unless there are CPUs that advertise NEON 
> > > > > > > support
> > > > > > > but don't actually support it.
> > > > > > >
> > > > > >
> > > > > > I think the issue will result in a compiler error perhaps when neon 
> > > > > > is
> > > > > > disabled via
> > > > > > compiler command line which would be the case when neon is not in 
> > > > > > TUNE_FEATURES
> > > > > > the compiler might warn or error out when it finds neon instructions
> > > > > > being compiled via inline
> > > > > > assembly.  you just can try passing something like -mfpu=vfpv3d16 or
> > > > > > some such and see if
> > > > > > compiler/assembler complains during build, if not then perhaps its 
> > > > > > fine.
> > > > >
> > > > > If the last -mfpu is something else than neon, then including
> > > > > arm_neon.h will succeed but compiling neon code will fail.
> > > > >
> > > > > I did some experiments, and what I found was that when I remove neon
> > > > > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very
> > > > > early in the compiler command line. PulseAudio adds -mfpu=neon to
> > > > > CFLAGS when building neon code, and the last -mfpu wins, so the neon
> > > > > code gets built without errors.
> > > > >
> > > > > The configure check in PulseAudio only checks that the compiler 
> > > > > accepts
> > > > > -mfpu=neon and #include , it doesn't try to compile any
> > > > > actual neon code. This means that if the user adds -mfpu=vfp (or other
> > > > > non-neon) to CFLAGS rather than CC, configure will pass but building
> > > > > will fail. Is this something to guard against? A default qemuarm build
> > > > > doesn't do this, so I don't know if this ever happens in OE.
> > > > >
> > > > > I don't know yet how Meson behaves, I'll continue testing...
> > > >
> > > > I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC.
> > > > Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I
> > > > tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is
> > > > enabled in any case.
> > > >
> > > > So, Meson seems pretty safe, although I guess it would be nice not to
> > 

  1   2   3   4   5   6   7   8   9   10   >