Re: [oe-core][PATCH] libpng: Added "--enable-hardware-optimizations" instead of "--enable-arm-neon". Because "--enable-arm-neon" only works for armv7, but doesn't work for aarch64. But in fact neon is
On Mon, Dec 12, 2022 at 6:38 PM leimaohui wrote:
>
> Reference to libpng-1.6.38/configure,if enable_hardware_optimizations is
> enabled, libpng can judge whether enable enable_arm_neon according
> to $host_cpu.
>
> $ cat libpng-1.6.38/configure
> ..
> if test ${enable_hardware_optimizations+y}
> then :
> ..
> # allow enabling hardware optimization on any system:
> case "$host_cpu" in
> arm*|aarch64*)
> enable_arm_neon=yes
>
> printf "%s\n" "#define PNG_ARM_NEON_OPT 2" >>confdefs.h
> ..
>
>
> Signed-off-by: Lei Maohui
> ---
> meta/recipes-multimedia/libpng/libpng_1.6.38.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.38.bb
> b/meta/recipes-multimedia/libpng/libpng_1.6.38.bb
> index dc627203ef..7da71d9d3b 100644
> --- a/meta/recipes-multimedia/libpng/libpng_1.6.38.bb
> +++ b/meta/recipes-multimedia/libpng/libpng_1.6.38.bb
> @@ -22,7 +22,7 @@ BINCONFIG = "${bindir}/libpng-config
> ${bindir}/libpng16-config"
> inherit autotools binconfig-disabled pkgconfig
>
> # Work around missing symbols
> -EXTRA_OECONF:append:class-target = " ${@bb.utils.contains("TUNE_FEATURES",
> "neon", "--enable-arm-neon=on", "--enable-arm-neon=off", d)}"
> +EXTRA_OECONF:append:class-target = " --enable-hardware-optimizations=on "
It's difficult (impossible?) to automatically detect whether an ARM
target supports NEON at build time, so this looks unlikely to work.
Testing for NEON either needs to happen at run time or the information
needs to be passed from the build system as an explicit configure
option (ie the original approach here).
If you don't want to pass NEON options to 64bit ARM targets then add
an over-ride which only applies to 32bit ARM targets.
Or in this case, if the configure script is wrong to try to enable
NEON for 64bit ARM targets, patch the configure script and submit the
patch upstream.
> PACKAGES =+ "${PN}-tools"
>
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174545):
https://lists.openembedded.org/g/openembedded-core/message/174545
Mute This Topic: https://lists.openembedded.org/mt/95637494/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] bitbake.conf: Define TC_CXX_RUNTIME
On Fri, Sep 9, 2022 at 9:52 AM Khem Raj wrote:
>
> This variable is used to denote the C/C++ compiler runtime to use.
> Right now there are few alternatives out of the core which could
> use this variable to define this property, the values it can take
> are 'gnu' for gcc runtime. 'llvm' for using compiler-rt+libc++ and
> 'android' to use android runtime. Default settings is to use gnu
> which is current silent default also.
Seems like you made a conscious decision to refer to the gcc runtime
library as "gnu" instead of "gcc". What was the reasoning? Using "gcc"
would seem to be clearer unless it clashes with some gcc upstream
naming convention.
> Signed-off-by: Khem Raj
> ---
> v2: Document the variable
> v3: Rename to TC_CXX_RUNTIME
>
> documentation/ref-manual/variables.rst | 6 ++
> meta/conf/bitbake.conf | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/documentation/ref-manual/variables.rst
> b/documentation/ref-manual/variables.rst
> index cf817e9540..2d28c3d2f7 100644
> --- a/documentation/ref-manual/variables.rst
> +++ b/documentation/ref-manual/variables.rst
> @@ -7973,6 +7973,12 @@ system and gives an overview of their function and
> contents.
>toolchain. You can use ``meta-sourcery`` as a template for adding
>support for other external toolchains.
>
> + :term:`TC_CXX_RUNTIME`
> + Specifies the C/C++ STL and runtime variant to use during
> + the build process. Default value is 'gnu'
> +
> + You can select "gnu", "llvm", or "android".
> +
> :term:`TEMPLATECONF`
>Specifies the directory used by the build system to find templates
>from which to build the ``bblayers.conf`` and ``local.conf`` files.
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 52a36d788b..62cdd9aa9c 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -389,6 +389,7 @@ FILESYSTEM_PERMS_TABLES ?= "${@'files/fs-perms.txt' if
> oe.types.boolean(d.getVar
>
> TCMODE ??= "default"
> TCLIBC ??= "glibc"
> +TC_CXX_RUNTIME ??= "gnu"
> TMPDIR ?= "${TOPDIR}/tmp"
>
> CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' +
> str(d.getVar('MACHINE'))][bool(d.getVar('MACHINE'))]}${@['', '/' +
> str(d.getVar('SDKMACHINE'))][bool(d.getVar('SDKMACHINE'))]}"
> --
> 2.37.3
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170504):
https://lists.openembedded.org/g/openembedded-core/message/170504
Mute This Topic: https://lists.openembedded.org/mt/93577585/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] zip: Enable largefile support based on distro feature
On Wed, Aug 10, 2022 at 10:54 PM Khem Raj wrote:
>
> The configure test tries to run a binary during build to determine
> largefile support, which wont work in cross-compile mode, therefore
> specify it when largefile DISTRO_FEATURE is on.
>
> Signed-off-by: Khem Raj
> ---
> meta/recipes-extended/zip/zip_3.0.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-extended/zip/zip_3.0.bb
> b/meta/recipes-extended/zip/zip_3.0.bb
> index 07a67b96348..d560c83464b 100644
> --- a/meta/recipes-extended/zip/zip_3.0.bb
> +++ b/meta/recipes-extended/zip/zip_3.0.bb
> @@ -29,6 +29,8 @@ CVE_CHECK_IGNORE += "CVE-2018-13410"
> # Not for zip but for smart contract implementation for it
> CVE_CHECK_IGNORE += "CVE-2018-13684"
>
> +CFLAGS += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile',
> '-DLARGE_FILE_SUPPORT', '', d)}"
This should be hardcoded to enable LFS. The largefile distro feature
isn't used in oe-core (ie disabling LFS is not supported or even
possible anymore). The distro feature should be removed completely at
some point... when recipes in meta-oe etc have stopped referring to
it. See release notes from OE 2.3 (ie May 2017):
https://docs.yoctoproject.org/2.3/ref-manual/ref-manual.html#migration-2.3-miscellaneous-changes
> # zip.inc sets CFLAGS, but what Makefile actually uses is
> # CFLAGS_NOOPT. It will also force -O3 optimization, overriding
> # whatever we set.
> --
> 2.37.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169291):
https://lists.openembedded.org/g/openembedded-core/message/169291
Mute This Topic: https://lists.openembedded.org/mt/92953016/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][PATCH v2] classes: rootfs-postcommands: autologin root on serial-getty
On Tue, Jul 26, 2022 at 2:39 AM Johannes Schneider via
lists.openembedded.org
wrote:
>
> when empty-root-password AND serial-autologin-root are part of the
> IMAGE_FEATURES, save some of the developers time by not having to type
> the (then still sole) 'root' username on the serial consoleafter each
> and every reboot
>
> this is done by inserting '--autologin root' into the command line of
> the responsible 'getty' service
>
> Signed-off-by: Johannes Schneider
> ---
> meta/classes/image.bbclass | 2 +-
> meta/classes/rootfs-postcommands.bbclass | 15 +++
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 2139a7e576..fe32cdefd5 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -34,7 +34,7 @@ INHIBIT_DEFAULT_DEPS = "1"
> # IMAGE_FEATURES may contain any available package group
> IMAGE_FEATURES ?= ""
> IMAGE_FEATURES[type] = "list"
> -IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs
> read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password
> allow-empty-password allow-root-login post-install-logging overlayfs-etc"
> +IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs
> read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password
> allow-empty-password allow-root-login serial-autologin-root
> post-install-logging overlayfs-etc"
>
> # Generate companion debugfs?
> IMAGE_GEN_DEBUGFS ?= "0"
> diff --git a/meta/classes/rootfs-postcommands.bbclass
> b/meta/classes/rootfs-postcommands.bbclass
> index a8a952f31d..e8e9661f58 100644
> --- a/meta/classes/rootfs-postcommands.bbclass
> +++ b/meta/classes/rootfs-postcommands.bbclass
> @@ -8,6 +8,9 @@ ROOTFS_POSTPROCESS_COMMAND +=
> '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'deb
> # Allow dropbear/openssh to accept root logins if debug-tweaks or
> allow-root-login is enabled
> ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [
> 'debug-tweaks', 'allow-root-login' ], "ssh_allow_root_login; ", "",d)}'
>
> +# Autologin the root user on the serial console, if empty-root-password and
> serial-autologin-root are active
> +ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", [
> 'empty-root-password', 'serial-autologin-root' ], "serial_autologin_root; ",
> "",d)}'
> +
> # Enable postinst logging if debug-tweaks or post-install-logging is enabled
> ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [
> 'debug-tweaks', 'post-install-logging' ], "postinst_enable_logging; ", "",d)}'
>
> @@ -196,6 +199,18 @@ ssh_allow_root_login () {
> fi
> }
>
> +#
> +# Autologin the 'root' user on the serial terminal,
> +# if empty-root-password is enabled
Comment should be updated too "... if empty-root-password and
serial-autologin-root are both enabled".
> +#
> +serial_autologin_root () {
> + if [ -e
> ${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service ]; then
> + sed -i '/^\s*ExecStart\b/ s/getty /&--autologin root /' \
> +
> "${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service"
> + fi
> +}
> +
> +
> python sort_passwd () {
> import rootfspostcommands
> rootfspostcommands.sort_passwd(d.expand('${IMAGE_ROOTFS}${sysconfdir}'))
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168510):
https://lists.openembedded.org/g/openembedded-core/message/168510
Mute This Topic: https://lists.openembedded.org/mt/92623778/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 1/2] poky-altcfg: enable usrmerge
On Wed, Jul 13, 2022 at 12:02 PM Luca Bocassi wrote: > > On Wed, 13 Jul 2022 at 19:36, Richard Purdie > wrote: > > > > On Wed, 2022-07-13 at 19:09 +0100, Luca Boccassi wrote: > > > On Wed, 13 Jul 2022 at 18:53, Richard Purdie > > > wrote: > > > > > > > > On Wed, 2022-07-13 at 17:55 +0100, Luca Bocassi wrote: > > > > > From: Luca Boccassi > > > > > > > > > > Ensure it gets tested by the CI > > > > > > > > > > Signed-off-by: Luca Boccassi > > > > > --- > > > > > meta-poky/conf/distro/poky-altcfg.conf | 2 ++ > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > diff --git a/meta-poky/conf/distro/poky-altcfg.conf > > > > > b/meta-poky/conf/distro/poky-altcfg.conf > > > > > index f03306e798..57a76e8bb9 100644 > > > > > --- a/meta-poky/conf/distro/poky-altcfg.conf > > > > > +++ b/meta-poky/conf/distro/poky-altcfg.conf > > > > > @@ -9,6 +9,8 @@ DISTROOVERRIDES = "poky:poky-altcfg" > > > > > #DISTROOVERRIDES = "poky:linuxstdbase" > > > > > > > > > > INIT_MANAGER:poky-altcfg = "systemd" > > > > > +# systemd will soon require usrmerge > > > > > +DISTRO_FEATURES:poky-altcfg += "usrmerge" > > > > > # systemd isn't suitable with musl > > > > > INIT_MANAGER:poky-altcfg:libc-musl = "sysvinit" > > > > > > > > > > > > > This blew up builds since it clears everything else out of > > > > DISTRO_FEATURES which isn't what was intended. I've tweaked the patch > > > > and re-queued. > > > > > > Sorry, did I get something wrong? The diff between my local branch and > > > the master-next branch is empty, can't quite see it: > > > > > > $ git diff upstream/master-next meta-poky/conf/distro/poky-altcfg.conf > > > $ > > > > My fault, I'm trying to restart the build from a different environment > > to usual and I messed up the change. It should be there now (and build > > restarted). > > No worries - I see, in this case the append was the right thing. One > day I'll get these right on the first try. One day! Thanks for the > fix. Yeah... += with an over-ride is intuitive but 99.9% of the time is completely wrong. There was a discussion some time ago about having the parser reject it with an error because it repeatedly trips up new (and some not so new...) developers, but it never came to anything. > Kind regards, > Luca Boccassi > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167995): https://lists.openembedded.org/g/openembedded-core/message/167995 Mute This Topic: https://lists.openembedded.org/mt/92361983/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] [RFC PATCH] bitbake-layers: add layer repositories/revisions save and restore tooling (aka 'layer configuration')
On Sat, Jul 2, 2022 at 4:13 AM Richard Purdie wrote: > > I admit I've been putting off this topic for a long time. I actually > wrote up something about it about 5 years ago. I sent it to four people > to get some opinions. The six opinions I got back made me despair. i > have had a while to think about it though. > > The challenge is that everyone has a workflow they like today and they > will tend to dislike anything that looks different. For that reason I > think we need a high level tool which can work with the different > approaches. Once we have that, I suspect we'll see some grow stronger > and some will wither off, which is probably as it should be through > natural evolution. The approach Alex has taken here does head in that > direction but I'm not sure it goes quite far enough to get the fraction > of users we need on board. > > I'm not going to comment directly on Alex's proposal at this point, I'd > like to put some ideas out there and see what people think of them. I > think you'll see that I'm in agreement with the idea/direction but I > have a slightly bigger idea of how to do it, which will both be harder > to implement but also have a better chance of getting more people on > board. > > So, let me go into a proposal of what I think the tool we need looks > like. I propose we create a new tool, lets call it "oe-setup". It is a > standalone project in it's own git repo and it's first command would be > "init" with a command line looking roughly like: > > oe-setup init > oe-setup init > oe-setup init > oe-setup init > oe-setup init > > The idea being that the repository has some "pre-canned" idea of > certain project names, e.g. poky, yoe and whatever else we decide to > support "out the box" (criteria tbd). Those project names have a > default pre-canned config, or set of configs (e.g. taking branch/series > names) so I'd want to see these all work: My proposal would be to try to reuse Linux kconfig. Users know how to run "make oldconfig", "make menuconfig", etc and I believe all key distro / machine configuration along with which meta layers should be enabled, which branch to use, etc can all be captured within a kconfig .config file. The task at hand would then become writing a tool to translate from a .config file to a set of distro, machine, local.conf config files (and an image recipe?) + drive whichever tool will be used to fetch meta layer git repos. The "pre-canned" knowledge of poky, yoe, etc then just becomes a set of alternative defconfig files. Although if we can generate distro configs on the fly from a defconfig file then separate meta layers to hold distro configs starts to become redundant... As a reminder, here's the Buildroot README: https://github.com/buildroot/buildroot/blob/master/README With those first 2 steps a Buildroot user can effectively create their own custom distro and machine config... all from within the user-friendly menuconfig environment. The OE equivalent (Yocto Quick Start) is not only more complex and only tells a user how to build someone else's preset configurations. Creating a custom distro and machine config in OE is beyond the quick start and requires a full knowledge of bitbake syntax etc, etc. > oe-setup init poky . > oe-setup init poky dunfell . > oe-setup init poky ./my-local-config.json . > oe-setup init poky http://someserver/my-remote-config.json . > > We'd also allow something not in the default like of project names to > be used directly with a url, or maybe added with an "add-project" > command. This could work against a user local config file, a bit like > git does with global config and adding remotes to a repo. > > You'll note I haven't made any mention of the tooling these use. The > reason is that we don't actually care. I'd propose we teach the tool > about a few common standards (kas, submodules, repo) in the form of > plugins and then hand off to those tools to do the setup. I'd also > propose we develop a "native" form where they perhaps aren't needed. > the nice thing is we can have several "native" forms if needed so if > one approach isn't working or we need to change it, we can. > > We may also want to consider an optional "sub-config" parameter which > gets passed along to the underlying tool. > > One of my conclusions after thinking about this for a long time is we > have a bootstrap problem. If everyone used git and git worked > everywhere, things would be easier. They don't and it doesn't. My > evidence? The bitbake fetcher. Much of the ugliness the bitbake fetcher > deals with applies to layers as well. Some people need proxy support, > some need mirror tarballs, some need floating revisions, some need > complete lock down and so on. > > We could simplify the problem and just say those users "can manage". If > we do that, we're giving up at the first hurdle on the idea what we can > have a (mostly) universal tool. I'm not sure I'm quite ready to do > that. > > Like most more seasoned developers, I
Re: [OE-core] [PATCH] ccache.bbclass: document CCACHE_MAXSIZE variable
On Thu, May 26, 2022 at 5:06 PM Zach Welch wrote:
>
> Setting this avoids premature cache object eviction during large builds.
>
> Signed-off-by: Zachary T Welch
> ---
> meta/classes/ccache.bbclass | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/ccache.bbclass b/meta/classes/ccache.bbclass
> index 4532894c57..913304ab35 100644
> --- a/meta/classes/ccache.bbclass
> +++ b/meta/classes/ccache.bbclass
> @@ -12,7 +12,12 @@
> # Set CCACHE_TOP_DIR to a shared dir
> # CCACHE_TOP_DIR = /path/to/shared_ccache/
> #
> -# - TO debug ccahe
> +# - Adjust the ccache size limit to avoid overflow during large builds:
> +# export CCACHE_MAXSIZE = "100G"
> +# To find a reasonable limit, set this limit to 0 (no limit), then
> +# observe how large the ccache directory grows.
The default (ie 5GB) would seem safer for most users. Apart from some
potential loss in performance, there's no downside to reaching the
limit (i.e. there's no "overflow" as you describe it) and 5GB of
compressed object code is already quite a lot. Growing much beyond
that risks just filling the cache up with old stuff that's never going
to be reused anyway.
What kind of "large builds" are you seeing issues with?
> +# - To debug ccache:> # export CCACHE_DEBUG = "1"
> # export CCACHE_LOGFILE = "${CCACHE_DIR}/logfile.log"
> # And also set PARALLEL_MAKE = "-j 1" to get make the log in order
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#166199):
https://lists.openembedded.org/g/openembedded-core/message/166199
Mute This Topic: https://lists.openembedded.org/mt/91366715/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] sanity: skip make 4.2.1 warning for debian
On Wed, Apr 27, 2022 at 3:40 AM Richard Purdie wrote: > > On Tue, 2022-04-26 at 14:39 -0700, Andre McCurdy wrote: > > On Tue, Apr 26, 2022 at 1:56 PM Khem Raj wrote: > > > > > > On Tue, Apr 26, 2022 at 1:51 PM Andre McCurdy wrote: > > > > > > > > On Tue, Apr 26, 2022 at 12:46 PM Nicolas Dechesne > > > > wrote: > > > > > > > > > > This is a follow up patch of: > > > > > ad5829aa1f8a (sanity: Show a warning that make 4.2.1 is buggy on > > > > > non-ubuntu systems) > > > > > > > > > > Debian10 has the exact same version/sources for make as Ubuntu > > > > > (focal), e.g. https://packages.debian.org/source/buster/make-dfsg and > > > > > https://packages.ubuntu.com/source/focal/make-dfsg. > > > > > > > > > > As per the corresponding changelog, the patch mentioned in > > > > > ad5829aa1f8a, is included in both Debian and Ubuntu in make > > > > > 4.2.1-1.1. So it's safe to use make 4.2.1 in Debian10. > > > > > > > > > > Signed-off-by: Nicolas Dechesne > > > > > --- > > > > > meta/classes/sanity.bbclass | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass > > > > > index c385d92e8b..c72a7b3ed3 100644 > > > > > --- a/meta/classes/sanity.bbclass > > > > > +++ b/meta/classes/sanity.bbclass > > > > > @@ -470,7 +470,7 @@ def check_make_version(sanity_data): > > > > > > > > > > if bb.utils.vercmp_string_op(version, "4.2.1", "=="): > > > > > distro = oe.lsb.distro_identifier() > > > > > > > > Not directly related to your change, but shouldn't this be > > > > lsb_distro_identifier() instead of oe.lsb.distro_identifier()? > > > > > > lsb_distro_identifier would work when it is inheriting base.bbclass > > > otherwise the utility function is needed. > > > > Question isn't really whether it will work or not (if it doesn't work, > > we should make it work) but rather whether any user-defined > > LSB_DISTRO_ADJUST should be applied before checking if the host distro > > is based on Debian/Ubuntu or not. > > It would help to be a little more specific with the background. Having looked > at > the code, we have two lsb functions, one in base.bbclass and one in > oe/lib/lsb.py. The one in base.bbclass is a wrapper which uses > LSB_DISTRO_ADJUST. > > As far as I know, we don't use LSB_DISTRO_ADJUST in core at all. I suspect it > should really probably be added to the lsb.py function in most cases. Is there > any documentation or other info about when it should be applied and when it > should not? Adding LSB_DISTRO_ADJUST directly to lsb.py would be fine I think. Personally I use LSB_DISTRO_ADJUST to map Linux Mint to Ubuntu. Linux Mint is binary compatible with Ubuntu (created from Ubuntu package feeds). The LSB_DISTRO_ADJUST mapping allows native sstate from a build server running Ubuntu to be reused on a developer laptop running Linux Mint. https://github.com/lgirdk/meta-mng/blob/ofw/conf/distro/include/mng-sstate.inc If the make 4.2.1 sanity check were to include LSB_DISTRO_ADJUST then (for me at least) it would suppress unnecessary warnings when running on Linux Mint (ie with the Ubuntu version of make). But in general, if we give users a method to adjust how their host distro is identified then we should enable it consistently unless there's a clear reason not to. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#164929): https://lists.openembedded.org/g/openembedded-core/message/164929 Mute This Topic: https://lists.openembedded.org/mt/90716488/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] sanity: skip make 4.2.1 warning for debian
On Tue, Apr 26, 2022 at 1:56 PM Khem Raj wrote: > > On Tue, Apr 26, 2022 at 1:51 PM Andre McCurdy wrote: > > > > On Tue, Apr 26, 2022 at 12:46 PM Nicolas Dechesne > > wrote: > > > > > > This is a follow up patch of: > > > ad5829aa1f8a (sanity: Show a warning that make 4.2.1 is buggy on > > > non-ubuntu systems) > > > > > > Debian10 has the exact same version/sources for make as Ubuntu > > > (focal), e.g. https://packages.debian.org/source/buster/make-dfsg and > > > https://packages.ubuntu.com/source/focal/make-dfsg. > > > > > > As per the corresponding changelog, the patch mentioned in > > > ad5829aa1f8a, is included in both Debian and Ubuntu in make > > > 4.2.1-1.1. So it's safe to use make 4.2.1 in Debian10. > > > > > > Signed-off-by: Nicolas Dechesne > > > --- > > > meta/classes/sanity.bbclass | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass > > > index c385d92e8b..c72a7b3ed3 100644 > > > --- a/meta/classes/sanity.bbclass > > > +++ b/meta/classes/sanity.bbclass > > > @@ -470,7 +470,7 @@ def check_make_version(sanity_data): > > > > > > if bb.utils.vercmp_string_op(version, "4.2.1", "=="): > > > distro = oe.lsb.distro_identifier() > > > > Not directly related to your change, but shouldn't this be > > lsb_distro_identifier() instead of oe.lsb.distro_identifier()? > > lsb_distro_identifier would work when it is inheriting base.bbclass > otherwise the utility function is needed. Question isn't really whether it will work or not (if it doesn't work, we should make it work) but rather whether any user-defined LSB_DISTRO_ADJUST should be applied before checking if the host distro is based on Debian/Ubuntu or not. > > > -if "ubuntu" in distro: > > > +if "ubuntu" in distro or "debian" in distro: > > > return None > > > return "make version 4.2.1 is known to have issues on > > > Centos/OpenSUSE and other non-Ubuntu systems. Please use a > > > buildtools-make-tarball or a newer version of make.\n" > > > return None > > > -- > > > 2.36.0 > > > > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#164885): https://lists.openembedded.org/g/openembedded-core/message/164885 Mute This Topic: https://lists.openembedded.org/mt/90716488/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] sanity: skip make 4.2.1 warning for debian
On Tue, Apr 26, 2022 at 12:46 PM Nicolas Dechesne wrote: > > This is a follow up patch of: > ad5829aa1f8a (sanity: Show a warning that make 4.2.1 is buggy on non-ubuntu > systems) > > Debian10 has the exact same version/sources for make as Ubuntu > (focal), e.g. https://packages.debian.org/source/buster/make-dfsg and > https://packages.ubuntu.com/source/focal/make-dfsg. > > As per the corresponding changelog, the patch mentioned in > ad5829aa1f8a, is included in both Debian and Ubuntu in make > 4.2.1-1.1. So it's safe to use make 4.2.1 in Debian10. > > Signed-off-by: Nicolas Dechesne > --- > meta/classes/sanity.bbclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass > index c385d92e8b..c72a7b3ed3 100644 > --- a/meta/classes/sanity.bbclass > +++ b/meta/classes/sanity.bbclass > @@ -470,7 +470,7 @@ def check_make_version(sanity_data): > > if bb.utils.vercmp_string_op(version, "4.2.1", "=="): > distro = oe.lsb.distro_identifier() Not directly related to your change, but shouldn't this be lsb_distro_identifier() instead of oe.lsb.distro_identifier()? > -if "ubuntu" in distro: > +if "ubuntu" in distro or "debian" in distro: > return None > return "make version 4.2.1 is known to have issues on > Centos/OpenSUSE and other non-Ubuntu systems. Please use a > buildtools-make-tarball or a newer version of make.\n" > return None > -- > 2.36.0 > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#164883): https://lists.openembedded.org/g/openembedded-core/message/164883 Mute This Topic: https://lists.openembedded.org/mt/90716488/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] devshell: introduce intercepts as per native / nativesdk
On Wed, Apr 20, 2022 at 8:12 AM Paul Gortmaker
wrote:
>
> In a devshell, recent versions of git will complain if the repo is owned
> by someone other than the current UID - consider this example:
>
> --
> bitbake -c devshell linux-yocto
>
> [...]
>
> kernel-source#git branch
> fatal: unsafe repository
> ('/home/paul/poky/build-qemuarm64/tmp/work-shared/qemuarm64/kernel-source' is
> owned by someone else)
> To add an exception for this directory, call:
>
> git config --global --add safe.directory
> /home/paul/poky/build-qemuarm64/tmp/work-shared/qemuarm64/kernel-source
> kernel-source#
> --
>
> Of course the devshell has UID zero and the "real" UID is for "paul" in
> this case. And so recent git versions complain.
>
> As the whole purpose of the devshell is to invoke a shell where development
> can take place, having a non-functional git is clearly unacceptable.
>
> Richard suggested we could use PSEUDO_UNLOAD=1 to evade this issue, and I
> suggested we probably will see other similar instances like this and should
> make use of PATH to intercept via devshell wrappers - conveniently we already
> have examples of this.
>
> Here, we copy the existing "ar" example and tune it to the needs of git to
> combine Richard's suggestion and mine.
>
> As such we now also can store commit logs and use send-email with our user
> specific settings, instead of "root", so in additon to fixing basic
> commands like "git branch" it should also increase general usefulness.
It looks like this will address the performance issues of using git
from a devshell too. Trying to run git log, git blame, etc for
largeish repos in a devshell is annoyingly slow due to the overhead of
pseudo.
I always wondered what people do in a devshell which actually _does_
need to run under pseudo...
> Cc: Richard Purdie
> Signed-off-by: Paul Gortmaker
>
> diff --git a/meta/classes/devshell.bbclass b/meta/classes/devshell.bbclass
> index 62dc958d9a4a..7ac134e0950f 100644
> --- a/meta/classes/devshell.bbclass
> +++ b/meta/classes/devshell.bbclass
> @@ -2,6 +2,8 @@ inherit terminal
>
> DEVSHELL = "${SHELL}"
>
> +PATH:prepend = "${COREBASE}/scripts/devshell-intercept:"
> +
> python do_devshell () {
> if d.getVarFlag("do_devshell", "manualfakeroot"):
> d.prependVar("DEVSHELL", "pseudo ")
> diff --git a/scripts/devshell-intercept/git b/scripts/devshell-intercept/git
> new file mode 100755
> index ..8adf5c9ecb71
> --- /dev/null
> +++ b/scripts/devshell-intercept/git
> @@ -0,0 +1,19 @@
> +#!/usr/bin/env python3
> +#
> +# Wrapper around 'git' that doesn't think we are root
> +
> +import os
> +import shutil
> +import sys
> +
> +os.environ['PSEUDO_UNLOAD'] = '1'
> +
> +# calculate path to the real 'git'
> +path = os.environ['PATH']
> +path = path.replace(os.path.dirname(sys.argv[0]), '')
> +real_git = shutil.which('git', path=path)
> +
> +if len(sys.argv) == 1:
> +os.execl(real_git, 'git')
> +
> +os.execv(real_git, sys.argv)
> --
> 2.17.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164739):
https://lists.openembedded.org/g/openembedded-core/message/164739
Mute This Topic: https://lists.openembedded.org/mt/90585970/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] buildtools: Add standalone make tarball
On Wed, Apr 13, 2022 at 10:58 AM Richard Purdie
wrote:
>
> Some versions of make have bugs. Add a way to provide a make tarball
> that can be used on it's own in these cases.
>
> Signed-off-by: Richard Purdie
> ---
> meta/conf/distro/include/maintainers.inc | 1 +
> .../recipes-core/meta/buildtools-make-tarball.bb | 16
> 2 files changed, 17 insertions(+)
> create mode 100644 meta/recipes-core/meta/buildtools-make-tarball.bb
>
> diff --git a/meta/conf/distro/include/maintainers.inc
> b/meta/conf/distro/include/maintainers.inc
> index 2c5e7308275..09a75933e26 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -84,6 +84,7 @@ RECIPE_MAINTAINER:pn-builder = "Richard Purdie
> RECIPE_MAINTAINER:pn-buildtools-extended-tarball = "Richard Purdie
> "
> RECIPE_MAINTAINER:pn-buildtools-tarball = "Richard Purdie
> "
> RECIPE_MAINTAINER:pn-buildtools-docs-tarball = "Richard Purdie
> "
> +RECIPE_MAINTAINER:pn-buildtools-make-tarball = "Richard Purdie
> "
> RECIPE_MAINTAINER:pn-busybox = "Andrej Valek "
> RECIPE_MAINTAINER:pn-busybox-inittab = "Denys Dmytriyenko "
> RECIPE_MAINTAINER:pn-bzip2 = "Denys Dmytriyenko "
> diff --git a/meta/recipes-core/meta/buildtools-make-tarball.bb
> b/meta/recipes-core/meta/buildtools-make-tarball.bb
> new file mode 100644
> index 000..e278f682719
> --- /dev/null
> +++ b/meta/recipes-core/meta/buildtools-make-tarball.bb
> @@ -0,0 +1,16 @@
> +require recipes-core/meta/buildtools-tarball.bb
> +
> +DESCRIPTION = "SDK type target for building a standalone tarball containing
> build-essentials, python3, chrpath, \
> + make, git and tar. The tarball can be used to run bitbake
> builds on systems which don't meet the \
> + usual version requirements and have ancient compilers."
Over enthusiastic copy and paste?
> +SUMMARY = "Standalone tarball for running builds on systems with inadequate
> software and ancient compilers"
> +LICENSE = "MIT"
> +
> +# Add nativesdk equivalent of build-essentials
> +TOOLCHAIN_HOST_TASK = "\
> +nativesdk-sdk-provides-dummy \
> +nativesdk-make \
> +"
> +TOOLCHAIN_OUTPUTNAME =
> "${SDK_ARCH}-buildtools-make-nativesdk-standalone-${DISTRO_VERSION}"
> +
> +SDK_TITLE = "Make build tool"
> --
> 2.32.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164362):
https://lists.openembedded.org/g/openembedded-core/message/164362
Mute This Topic: https://lists.openembedded.org/mt/90446806/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] glib-networking: build with gnutls support
On Sun, Apr 10, 2022 at 10:29 AM Markus Volk wrote:
>
> this fixes authentication issues with geary and tls connection
>
> Signed-off-by: Markus Volk
> ---
> meta/recipes-core/glib-networking/glib-networking_2.72.0.bb | 2 +-
> meta/recipes-support/gnutls/gnutls_3.7.4.bb | 2 +-
> meta/recipes-support/p11-kit/p11-kit_0.24.1.bb | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-core/glib-networking/glib-networking_2.72.0.bb
> b/meta/recipes-core/glib-networking/glib-networking_2.72.0.bb
> index d578f17aa5..73827b0a85 100644
> --- a/meta/recipes-core/glib-networking/glib-networking_2.72.0.bb
> +++ b/meta/recipes-core/glib-networking/glib-networking_2.72.0.bb
> @@ -11,7 +11,7 @@ DEPENDS = "glib-2.0"
>
> SRC_URI[archive.sha256sum] =
> "100aaebb369285041de52da422b6b716789d5e4d7549a3a71ba587b932e0823b"
>
> -PACKAGECONFIG ??= "openssl ${@bb.utils.contains('PTEST_ENABLED', '1',
> 'tests', '', d)}"
> +PACKAGECONFIG ??= "openssl gnutls ${@bb.utils.contains('PTEST_ENABLED', '1',
> 'tests', '', d)}"
This should either be gnutls or openssl, not both. But aside from
that, gnutls brings (L)GPLv3 issues and therefore should not be
enabled by default.
Are you saying that some glib-networking functionality works when
using gnutls but does not work when using openssl? If so, is it a
known limitation? Or a bug? If a bug, has it been reported upstream?
The commit message should explain those kinds of details.
> PACKAGECONFIG[gnutls] = "-Dgnutls=enabled,-Dgnutls=disabled,gnutls"
> PACKAGECONFIG[openssl] = "-Dopenssl=enabled,-Dopenssl=disabled,openssl"
> diff --git a/meta/recipes-support/gnutls/gnutls_3.7.4.bb
> b/meta/recipes-support/gnutls/gnutls_3.7.4.bb
> index b34eb7f5f0..c2bb1da8be 100644
> --- a/meta/recipes-support/gnutls/gnutls_3.7.4.bb
> +++ b/meta/recipes-support/gnutls/gnutls_3.7.4.bb
> @@ -27,7 +27,7 @@ SRC_URI[sha256sum] =
> "e6adbebcfbc95867de01060d93c789938cf89cc1d1f6ef9ef661890f62
>
> inherit autotools texinfo pkgconfig gettext lib_package gtk-doc
>
> -PACKAGECONFIG ??= "libidn ${@bb.utils.filter('DISTRO_FEATURES', 'seccomp',
> d)}"
> +PACKAGECONFIG ??= "libidn p11-kit ${@bb.utils.filter('DISTRO_FEATURES',
> 'seccomp', d)}"
>
> # You must also have CONFIG_SECCOMP enabled in the kernel for
> # seccomp to work.
> diff --git a/meta/recipes-support/p11-kit/p11-kit_0.24.1.bb
> b/meta/recipes-support/p11-kit/p11-kit_0.24.1.bb
> index 59cbb67961..32c382489e 100644
> --- a/meta/recipes-support/p11-kit/p11-kit_0.24.1.bb
> +++ b/meta/recipes-support/p11-kit/p11-kit_0.24.1.bb
> @@ -14,7 +14,7 @@ SRC_URI =
> "git://github.com/p11-glue/p11-kit;branch=master;protocol=https"
> SRCREV = "dd0590d4e583f107e3e9fafe9ed754149da335d0"
> S = "${WORKDIR}/git"
>
> -PACKAGECONFIG ??= ""
> +PACKAGECONFIG ??= "trust-paths"
> PACKAGECONFIG[manpages] = "-Dman=true,-Dman=false,libxslt-native"
> PACKAGECONFIG[trust-paths] =
> "-Dtrust_paths=/etc/ssl/certs/ca-certificates.crt,,,ca-certificates"
>
> @@ -29,4 +29,4 @@ FILES:${PN} += " \
> # PN contains p11-kit-proxy.so, a symlink to a loadable module
> INSANE_SKIP:${PN} = "dev-so"
>
> -BBCLASSEXTEND = "nativesdk"
> +BBCLASSEXTEND = "native nativesdk"
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#164212):
https://lists.openembedded.org/g/openembedded-core/message/164212
Mute This Topic: https://lists.openembedded.org/mt/90378285/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [oe] INCOMPATIBLE_LICENSES and WHITELIST_ usage
On Thu, Feb 17, 2022 at 3:01 PM Saul Wold wrote: > > Folks, > > I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used > and processed to possibly include a COMPATIBLE_LICENSES variable as > well, see PeterK's email [0] > > I am trying to determine the usage of WHITELIST_ which would be > used to override a license that might be listed in INCOMPATIBLE_LICENSES > variable. > > Randy and I have done a quick and dirty survey of a 100 or so layers > (thanks Randy) and could not find any real usage other than what's > currently in OE-Core for WHITELIST_GPL-3.0. > > If you are using WHITELIST_, please let me reply with your usage. Common case seems to be allowing gdb in debug builds of distros which are otherwise free of GPLv3 etc, e.g. https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/distro/include/gdbserver-gplv3.inc https://github.com/lgirdk/meta-mng/blob/ofw-2112.6/conf/distro/mng.conf -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161875): https://lists.openembedded.org/g/openembedded-core/message/161875 Mute This Topic: https://lists.openembedded.org/mt/89223138/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] busybox: refresh the defconfig from 1.33.0
On Mon, Dec 20, 2021 at 5:08 AM Martin Jansa wrote: > > Hi, > > I don't remember the details, but looks like not intended. I guess I was > running with default SRC_URI which contains syslog.cfg and other optional > fragments, can you please refresh it again with all .cfg files removed from > SRC_URI? Yes, when refreshing the defconfig you need to do it first with all config fragments disabled and then review and manually update the fragments as required as a second step. > Regards, > > On Thu, Dec 16, 2021 at 6:26 PM Jan Lübbe wrote: >> >> Hi Martin, >> >> I just noticed that since this change, syslogd is compiled in by default, >> even I >> have SRC_URI:remove = "file://syslog.cfg" in a bbappend. Is this intentional? >> Otherwise, I'd prefer change the back to disabled by default (SRC_URI still >> contains syslog.cfg by default). >> >> Regards, >> Jan >> >> On Wed, 2021-03-10 at 14:37 +0100, Martin Jansa wrote: >> > -# CONFIG_LOGREAD is not set >> > -# CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING is not set >> > -# CONFIG_SYSLOGD is not set >> > -# CONFIG_FEATURE_ROTATE_LOGFILE is not set >> > -# CONFIG_FEATURE_REMOTE_LOG is not set >> > -# CONFIG_FEATURE_SYSLOGD_DUP is not set >> > -# CONFIG_FEATURE_SYSLOGD_CFG is not set >> > -CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=0 >> > -# CONFIG_FEATURE_IPC_SYSLOG is not set >> > -CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=0 >> > -# CONFIG_FEATURE_KMSG_SYSLOG is not set >> > +CONFIG_LOGREAD=y >> > +CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y >> > +CONFIG_SYSLOGD=y >> > +CONFIG_FEATURE_ROTATE_LOGFILE=y >> > +CONFIG_FEATURE_REMOTE_LOG=y >> > +CONFIG_FEATURE_SYSLOGD_DUP=y >> > +CONFIG_FEATURE_SYSLOGD_CFG=y >> > +# CONFIG_FEATURE_SYSLOGD_PRECISE_TIMESTAMPS is not set >> > +CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=256 >> > +CONFIG_FEATURE_IPC_SYSLOG=y >> > +CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=64 >> > +CONFIG_FEATURE_KMSG_SYSLOG=y >> >> -- >> Pengutronix e.K. | | >> Steuerwalder Str. 21 | http://www.pengutronix.de/ | >> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159905): https://lists.openembedded.org/g/openembedded-core/message/159905 Mute This Topic: https://lists.openembedded.org/mt/81226966/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 2/2] vim: set PACKAGECONFIG idiomatically
On Fri, Dec 3, 2021 at 10:07 AM Andre McCurdy wrote: > > On Fri, Dec 3, 2021 at 2:06 AM Richard Purdie > wrote: > > > > On Fri, 2021-12-03 at 01:39 -0800, Andre McCurdy wrote: > > > On Wed, Dec 1, 2021 at 2:33 PM Richard Purdie > > > wrote: > > > > > > > > On Tue, 2021-11-30 at 13:45 -0800, Andre McCurdy wrote: > > > > > On Tue, Nov 30, 2021 at 1:20 PM Ross Burton > > > > > wrote: > > > > > > > > > > > > On Tue, 30 Nov 2021 at 19:32, Andre McCurdy > > > > > > wrote: > > > > > > > This isn't equivalent - it will cause a change in behaviour for > > > > > > > anyone > > > > > > > using PACKAGECONFIG += "foo" from a .bbappend. > > > > > > > > > > > > Correct, but this is likely the only recipe in the greater ecosystem > > > > > > which has this behaviour, so I'm not that bothered to be honest. :) > > > > > > > > > > The only recipe? There are many recipes which set a default > > > > > PACKAGECONFIG with ?= and many which set it with ??=. Your change is > > > > > effectively switching the vim recipe from one approach to the other. > > > > > The fact that adding PACKAGECONFIG options from a .bbappend with += > > > > > sometimes works OK and sometimes not is a source of confusion for new > > > > > users. > > > > > > > > > > You are right that no one seems to care though... > > > > > > > > Some of us very much do care, it is actually bothering me a lot and > > > > I've posted > > > > several times on the architecture list about this kind of issue. > > > > > > > > We haven't worked out what we can agree to do about it though :(. > > > > > > As a first, very easy, step, make a statement here on the mailing list > > > that all PACKAGECONFIG defaults should be assigned with ?= instead of > > > ??= and fix the recipes in oe-core accordingly. > > > > The question is whether we all agree on that and I'm not sure we all do. > > What are the possible objections? Any more feedback? The misconception that no one cares about improving this could be because discussions on the topic always seem to peter out leaving these unanswered questions. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159264): https://lists.openembedded.org/g/openembedded-core/message/159264 Mute This Topic: https://lists.openembedded.org/mt/87406894/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 2/2] vim: set PACKAGECONFIG idiomatically
On Fri, Dec 3, 2021 at 5:59 AM Peter Kjellerstedt wrote: > > > -Original Message- > > From: openembedded-core@lists.openembedded.org > c...@lists.openembedded.org> On Behalf Of Richard Purdie > > Sent: den 3 december 2021 11:07 > > To: Andre McCurdy > > Cc: Ross Burton ; OE Core mailing list > c...@lists.openembedded.org> > > Subject: Re: [OE-core] [PATCH v2 2/2] vim: set PACKAGECONFIG idiomatically > > > > On Fri, 2021-12-03 at 01:39 -0800, Andre McCurdy wrote: > > > On Wed, Dec 1, 2021 at 2:33 PM Richard Purdie > > > wrote: > > > > > > > > On Tue, 2021-11-30 at 13:45 -0800, Andre McCurdy wrote: > > > > > On Tue, Nov 30, 2021 at 1:20 PM Ross Burton > > wrote: > > > > > > > > > > > > On Tue, 30 Nov 2021 at 19:32, Andre McCurdy > > wrote: > > > > > > > This isn't equivalent - it will cause a change in behaviour for > > anyone > > > > > > > using PACKAGECONFIG += "foo" from a .bbappend. > > > > > > > > > > > > Correct, but this is likely the only recipe in the greater > > ecosystem > > > > > > which has this behaviour, so I'm not that bothered to be honest. > > :) > > > > > > > > > > The only recipe? There are many recipes which set a default > > > > > PACKAGECONFIG with ?= and many which set it with ??=. Your change is > > > > > effectively switching the vim recipe from one approach to the other. > > > > > The fact that adding PACKAGECONFIG options from a .bbappend with += > > > > > sometimes works OK and sometimes not is a source of confusion for > > new > > > > > users. > > > > > > > > > > You are right that no one seems to care though... > > > > > > > > Some of us very much do care, it is actually bothering me a lot and > > I've posted > > > > several times on the architecture list about this kind of issue. > > > > > > > > We haven't worked out what we can agree to do about it though :(. > > > > > > As a first, very easy, step, make a statement here on the mailing list > > > that all PACKAGECONFIG defaults should be assigned with ?= instead of > > > ??= and fix the recipes in oe-core accordingly. > > > > The question is whether we all agree on that and I'm not sure we all do. > > I definitely agree that using "??=" in the recipe for PACKAGECONFIG is > a bad idea. In all our own recipes we use "=" so that is what I would > prefer, but "?=" is ok and it would alleviate the need to use > PACKAGECONFIG:append in bbappends instead of "PACKAGECONFIG +=". > > The reason I think "=" is better than "?=" is that if you want to > override the PACKAGECONFIG in a bbappend, using "=" a second time will > work fine, and if you want to do the override in a configuration file > like local.conf, you would use PACKAGECONFIG:pn-foo, which also would > override whatever the recipe set using "=". So unless I am missing a > use case, there really isn't a need to use "?=". Using = would certainly be OK and an improvement over the current mess. The reason I'd still argue that ?= is better is that it gives a clear hint that PACKAGECONFIG values in recipes are something a user may want to review and consider changing. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159126): https://lists.openembedded.org/g/openembedded-core/message/159126 Mute This Topic: https://lists.openembedded.org/mt/87406894/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 2/2] vim: set PACKAGECONFIG idiomatically
On Fri, Dec 3, 2021 at 2:06 AM Richard Purdie wrote: > > On Fri, 2021-12-03 at 01:39 -0800, Andre McCurdy wrote: > > On Wed, Dec 1, 2021 at 2:33 PM Richard Purdie > > wrote: > > > > > > On Tue, 2021-11-30 at 13:45 -0800, Andre McCurdy wrote: > > > > On Tue, Nov 30, 2021 at 1:20 PM Ross Burton wrote: > > > > > > > > > > On Tue, 30 Nov 2021 at 19:32, Andre McCurdy > > > > > wrote: > > > > > > This isn't equivalent - it will cause a change in behaviour for > > > > > > anyone > > > > > > using PACKAGECONFIG += "foo" from a .bbappend. > > > > > > > > > > Correct, but this is likely the only recipe in the greater ecosystem > > > > > which has this behaviour, so I'm not that bothered to be honest. :) > > > > > > > > The only recipe? There are many recipes which set a default > > > > PACKAGECONFIG with ?= and many which set it with ??=. Your change is > > > > effectively switching the vim recipe from one approach to the other. > > > > The fact that adding PACKAGECONFIG options from a .bbappend with += > > > > sometimes works OK and sometimes not is a source of confusion for new > > > > users. > > > > > > > > You are right that no one seems to care though... > > > > > > Some of us very much do care, it is actually bothering me a lot and I've > > > posted > > > several times on the architecture list about this kind of issue. > > > > > > We haven't worked out what we can agree to do about it though :(. > > > > As a first, very easy, step, make a statement here on the mailing list > > that all PACKAGECONFIG defaults should be assigned with ?= instead of > > ??= and fix the recipes in oe-core accordingly. > > The question is whether we all agree on that and I'm not sure we all do. What are the possible objections? > > As a second step, the parser could generate a warning (or even an > > error) if any variable is assigned to with only ??= and += (the end > > result of that combination is not what any user would expect and I > > doubt if any legitimate use case relies on it). > > Would be interesting to see if there is valid use so it is probably worth some > tests/analysis. The ??= operator never did what I'd hoped it would in reality > sadly. I agree ??= is way overused and very often in places where ?= or a direct assignment would be better. I'm not the one accepting and merging patches though... you are! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159125): https://lists.openembedded.org/g/openembedded-core/message/159125 Mute This Topic: https://lists.openembedded.org/mt/87406894/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 2/2] vim: set PACKAGECONFIG idiomatically
On Wed, Dec 1, 2021 at 2:33 PM Richard Purdie wrote: > > On Tue, 2021-11-30 at 13:45 -0800, Andre McCurdy wrote: > > On Tue, Nov 30, 2021 at 1:20 PM Ross Burton wrote: > > > > > > On Tue, 30 Nov 2021 at 19:32, Andre McCurdy wrote: > > > > This isn't equivalent - it will cause a change in behaviour for anyone > > > > using PACKAGECONFIG += "foo" from a .bbappend. > > > > > > Correct, but this is likely the only recipe in the greater ecosystem > > > which has this behaviour, so I'm not that bothered to be honest. :) > > > > The only recipe? There are many recipes which set a default > > PACKAGECONFIG with ?= and many which set it with ??=. Your change is > > effectively switching the vim recipe from one approach to the other. > > The fact that adding PACKAGECONFIG options from a .bbappend with += > > sometimes works OK and sometimes not is a source of confusion for new > > users. > > > > You are right that no one seems to care though... > > Some of us very much do care, it is actually bothering me a lot and I've > posted > several times on the architecture list about this kind of issue. > > We haven't worked out what we can agree to do about it though :(. As a first, very easy, step, make a statement here on the mailing list that all PACKAGECONFIG defaults should be assigned with ?= instead of ??= and fix the recipes in oe-core accordingly. As a second step, the parser could generate a warning (or even an error) if any variable is assigned to with only ??= and += (the end result of that combination is not what any user would expect and I doubt if any legitimate use case relies on it). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159112): https://lists.openembedded.org/g/openembedded-core/message/159112 Mute This Topic: https://lists.openembedded.org/mt/87406894/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 2/2] vim: set PACKAGECONFIG idiomatically
On Tue, Nov 30, 2021 at 1:20 PM Ross Burton wrote: > > On Tue, 30 Nov 2021 at 19:32, Andre McCurdy wrote: > > This isn't equivalent - it will cause a change in behaviour for anyone > > using PACKAGECONFIG += "foo" from a .bbappend. > > Correct, but this is likely the only recipe in the greater ecosystem > which has this behaviour, so I'm not that bothered to be honest. :) The only recipe? There are many recipes which set a default PACKAGECONFIG with ?= and many which set it with ??=. Your change is effectively switching the vim recipe from one approach to the other. The fact that adding PACKAGECONFIG options from a .bbappend with += sometimes works OK and sometimes not is a source of confusion for new users. You are right that no one seems to care though... -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#158997): https://lists.openembedded.org/g/openembedded-core/message/158997 Mute This Topic: https://lists.openembedded.org/mt/87406894/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 2/2] vim: set PACKAGECONFIG idiomatically
On Tue, Nov 30, 2021 at 8:53 AM Ross Burton wrote:
>
> Don't set an empty default value and them immediately assign to it.
>
> Signed-off-by: Ross Burton
> ---
> meta/recipes-support/vim/vim.inc | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/meta/recipes-support/vim/vim.inc
> b/meta/recipes-support/vim/vim.inc
> index 6cdf157cb6..a0692755b6 100644
> --- a/meta/recipes-support/vim/vim.inc
> +++ b/meta/recipes-support/vim/vim.inc
> @@ -67,9 +67,7 @@ do_compile() {
> autotools_do_compile
> }
>
> -#Available PACKAGECONFIG options are gtkgui, acl, x11, tiny selinux,
> elfutils, nls
> -PACKAGECONFIG ??= ""
> -PACKAGECONFIG += " \
> +PACKAGECONFIG ??= "\
This isn't equivalent - it will cause a change in behaviour for anyone
using PACKAGECONFIG += "foo" from a .bbappend.
> ${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 gtkgui', '', d)} \
> nls \
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#158989):
https://lists.openembedded.org/g/openembedded-core/message/158989
Mute This Topic: https://lists.openembedded.org/mt/87406894/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
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
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
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
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
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
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
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
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?
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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?
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 +=
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?
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
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
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
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
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
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?
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
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?
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
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
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
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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}?
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
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
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
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
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
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
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
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
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
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
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 ?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
-=-=-=-=-=-=-=-=-=-=-=-
