Re: [OE-core] [PATCH 2/2] tcmode-default: Test gcc9 as default on everything except mips
On Sat, May 25, 2019 at 1:19 PM Richard Purdie
wrote:
>
> mips is the only rchitecture not working with gcc9, switch the others
> leaving mips on gcc 8.X until we can figure out the fix for that.
>
> Signed-off-by: Richard Purdie
> ---
> meta/conf/distro/include/tcmode-default.inc | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/conf/distro/include/tcmode-default.inc
> b/meta/conf/distro/include/tcmode-default.inc
> index 744c6c3247e..5c10a4bd0d7 100644
> --- a/meta/conf/distro/include/tcmode-default.inc
> +++ b/meta/conf/distro/include/tcmode-default.inc
> @@ -18,7 +18,9 @@ PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-initial =
> "${TCLIBC}-initial"
> PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial ?=
> "nativesdk-glibc-initial"
> PREFERRED_PROVIDER_virtual/gettext ??= "gettext"
>
> -GCCVERSION ?= "8.%"
> +GCCVERSION ?= "9.%"
> +GCCVERSION_mips ?= "8.%"
> +GCCVERSION_mips64 ?= "8.%"
maybe pin it for all mips using mipsarch override ?
> SDKGCCVERSION ?= "${GCCVERSION}"
> BINUVERSION ?= "2.32%"
> GDBVERSION ?= "8.3%"
> --
> 2.20.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ethtool: update to 5.1
Changelog:
* Feature: Add support for 200Gbps (50Gbps per lane) link mode
* Feature: simplify handling of PHY tunable downshift
* Feature: add support for PHY tunable Fast Link Down
* Feature: add PHY Fast Link Down tunable to man page
* Feature: Add a 'start N' option when specifying the Rx flow hash indirection
table.
* Feature: Add bash-completion script
* Feature: add 1baseR_FEC link mode name
* Fix: qsfp: fix special value comparison
* Feature: move option parsing related code into function
* Feature: move cmdline_coalesce out of do_scoalesce
* Feature: introduce new ioctl for per-queue settings
* Feature: support per-queue sub command --show-coalesce
* Feature: support per-queue sub command --coalesce
* Fix: fix up dump_coalesce output to match actual option names
* Feature: fec: add pretty dump
Signed-off-by: Oleksandr Kravchuk
---
.../ethtool/ethtool/avoid_parallel_tests.patch | 10 ++
.../ethtool/{ethtool_5.0.bb => ethtool_5.1.bb} | 7 ---
2 files changed, 10 insertions(+), 7 deletions(-)
rename meta/recipes-extended/ethtool/{ethtool_5.0.bb => ethtool_5.1.bb} (84%)
diff --git a/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
b/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
index b145188d7f..7a0e38a394 100644
--- a/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
+++ b/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
@@ -1,4 +1,4 @@
-From 1484545a150de79483b6e2a74be02ebd030f1920 Mon Sep 17 00:00:00 2001
+From 2ca4c2492c4a06b28012e3e1033d10aa48f153b4 Mon Sep 17 00:00:00 2001
From: Tudor Florea
Date: Wed, 28 May 2014 18:59:54 +0200
Subject: [PATCH] ethtool: use serial-tests config needed by ptest.
@@ -9,17 +9,16 @@ serial-tests is required to generate those targets.
Signed-off-by: Tudor Florea
Upstream-Status: Inappropriate
(default automake behavior incompatible with ptest)
-
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
-index e891d91..600f8a8 100644
+index 2941a65..b0a1896 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@ dnl Process this file with autoconf to produce a configure
script.
- AC_INIT(ethtool, 5.0, net...@vger.kernel.org)
+ AC_INIT(ethtool, 5.1, net...@vger.kernel.org)
AC_PREREQ(2.52)
AC_CONFIG_SRCDIR([ethtool.c])
-AM_INIT_AUTOMAKE([gnu])
@@ -27,3 +26,6 @@ index e891d91..600f8a8 100644
AC_CONFIG_HEADERS([ethtool-config.h])
AM_MAINTAINER_MODE
+--
+2.17.1
+
diff --git a/meta/recipes-extended/ethtool/ethtool_5.0.bb
b/meta/recipes-extended/ethtool/ethtool_5.1.bb
similarity index 84%
rename from meta/recipes-extended/ethtool/ethtool_5.0.bb
rename to meta/recipes-extended/ethtool/ethtool_5.1.bb
index 76cdf9c4e7..d379d93bcf 100644
--- a/meta/recipes-extended/ethtool/ethtool_5.0.bb
+++ b/meta/recipes-extended/ethtool/ethtool_5.1.bb
@@ -11,10 +11,11 @@ SRC_URI =
"${KERNELORG_MIRROR}/software/network/ethtool/ethtool-${PV}.tar.gz \
file://avoid_parallel_tests.patch \
"
-SRC_URI[md5sum] = "8998c9eb7e491b0aec420a807ce52ba6"
-SRC_URI[sha256sum] =
"cc53a6d4d5643f8993ef20d6b638f88d9035529a9e777e222073c3a5b9237178"
+SRC_URI[md5sum] = "5d3aad86aec055348a37e867695a744a"
+SRC_URI[sha256sum] =
"4edb1fa4d7cf5667a5958d4213f61609f96d02cda90d2b6ec440561f8f8ffbf2"
+
+inherit autotools ptest bash-completion
-inherit autotools ptest
RDEPENDS_${PN}-ptest += "make"
do_compile_ptest() {
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 2/2] lttng-tools: add lttng-modules to ptest dependencies
On Wed, 2019-05-22 at 22:21 +, Jonathan Rajotte wrote:
> The lttng-tools project is essentially a "tracer" controller, the tests
> depends heavily on lttng-ust and lttng-modules presence.
>
> Signed-off-by: Jonathan Rajotte
> ---
> meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> index f1bb7224f3..7e80bb45d1 100644
> --- a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> +++ b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM =
> "file://LICENSE;md5=01d7fc4496aacf37d90df90b90b0cac1 \
>
> DEPENDS = "liburcu popt libxml2 util-linux"
> RDEPENDS_${PN} = "libgcc"
> -RDEPENDS_${PN}-ptest += "make perl bash gawk ${PN} babeltrace procps
> perl-module-overloading coreutils util-linux kmod"
> +RDEPENDS_${PN}-ptest += "make perl bash gawk ${PN} babeltrace procps
> perl-module-overloading coreutils util-linux kmod lttng-modules"
> RDEPENDS_${PN}-ptest_append_libc-glibc = " glibc-utils"
> RDEPENDS_${PN}-ptest_append_libc-musl = " musl-utils"
> # babelstats.pl wants getopt-long
Thanks for these patches, this will help a lot.
This patch threw up some issues in testing since kernel modules are
machine specific and this then means lttng-tools should become machine
specfic too (which is a bad idea and not necessary).
I've sent out an additional patch which resolved that, not as neatly as
I'd like as I had to special case lttng-modules in the mutilib code.
It gets this merged though as I'd like to stop seeing those timeouts
once and for all!
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] layer.conf: Whitelist lttng-tools->lttng-modules dependency
The API between lttng-tools and lttng-modules is safe, whitelist it as
the dependency fixes tools failures. This needs a hack in the multilib
class as right now there is no way to know if a given recipe is a kernel
module or not. This needs to be revisited.
Signed-off-by: Richard Purdie
---
meta/classes/multilib_global.bbclass | 3 +++
meta/conf/layer.conf | 1 +
2 files changed, 4 insertions(+)
diff --git a/meta/classes/multilib_global.bbclass
b/meta/classes/multilib_global.bbclass
index 649cc096b76..19ce1a50915 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -118,6 +118,9 @@ def preferred_ml_updates(d):
d.renameVar(prov, provexp)
def translate_provide(prefix, prov):
+# Really need to know if kernel modules class is inherited somehow
+if prov == "lttng-modules":
+return prov
if not prov.startswith("virtual/"):
return prefix + "-" + prov
if prov == "virtual/kernel":
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 6590e80700a..5ecb93651e5 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -77,6 +77,7 @@ SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
weston-init->weston \
weston-init->kbd \
connman->xl2tpd \
+ lttng-tools->lttng-modules \
"
# Avoid adding bison-native to the sysroot without a specific
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] tcmode-default: Test gcc9 as default on everything except mips
mips is the only rchitecture not working with gcc9, switch the others
leaving mips on gcc 8.X until we can figure out the fix for that.
Signed-off-by: Richard Purdie
---
meta/conf/distro/include/tcmode-default.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 744c6c3247e..5c10a4bd0d7 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -18,7 +18,9 @@ PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-initial =
"${TCLIBC}-initial"
PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial ?=
"nativesdk-glibc-initial"
PREFERRED_PROVIDER_virtual/gettext ??= "gettext"
-GCCVERSION ?= "8.%"
+GCCVERSION ?= "9.%"
+GCCVERSION_mips ?= "8.%"
+GCCVERSION_mips64 ?= "8.%"
SDKGCCVERSION ?= "${GCCVERSION}"
BINUVERSION ?= "2.32%"
GDBVERSION ?= "8.3%"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] elfutils: fix ptest failures
On Wed, 2019-05-22 at 17:11 +0800, mingli...@windriver.com wrote:
> From: Mingli Yu
>
> * Add missing -ptest package dependencies (needs
> ${PN}-dbg)
>
> * Add missing files which needed by ptest test
> to fix below failures:
> | ./run-ar.sh: line 23: cd:
> /usr/lib64/elfutils/ptest/tests/..//src: No such file or directory
> | FAIL: run-ar.sh
>
> | sh: ../src/elflint: No such file or directory
> | FAIL: asm-tst4
>
> * Rework 0001-skip-the-test-when-gcc-not-deployed.patch
> to skip the tests which depend on gcc
>
> Before:
>
> Recipe | Passed| Failed | Skipped
>
> elfutils | 176 | 23 | 4
>
>
> After:
>
> Recipe | Passed| Failed | Skipped
>
> elfutils | 184 | 15 | 4
>
>
Unfortunately if I add this to the build we see failures due to core-
image-sato-sdk-ptest becomming too large for generix86-64 as the image
exceeds the 4GB limit its FSTYPE allows.
I tried reducing the amount of free space in the image but then the
strace and until-linux ptests fail:
https://autobuilder.yocto.io/pub/non-release/20190524-8/testresults/testresult-report.txt
We do plan to change the hddimg format and use wic to avoid the 4GB
limit sometime in 2.8 but those patches aren't ready yet. I'm therefore
not quite sure what to do here. Is there any way we can save space in
the images so we could merge this?
Wth regard to the src/ directory, I did wonder if there needed to be a
patch to one of the other scripts to use installed files (similar to
how I fixed some of these last time)?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] alsa-utils: fix multilib names
On Sat, 2019-05-25 at 17:04 +0100, Burton, Ross wrote: > In related news I've been meaning to gut the alsa-utils recipe as > that's the last recipe that actually depends on gtk2. You mean alsa-tools, not alsa-utils, right? I won't object removing alsa-tools from OE Core. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] alsa-utils: fix multilib names
On Fri, 24 May 2019 at 19:59, Tanu Kaskinen wrote: > 18575b082a4042376fd1575465e69562dea04ddc added bash as a dependency of > alsa-utils-alsaconf so that the script interpreter will be available at > run time. However, this has the undesirable side effect of making bash > be a build dependency for alsa-utils and, for those folks who don't need > alsaconf but do want some other part of alsa-utils, this cure is worse > than the original disease. Avoiding building bash seems like quite an overreaction. I'd say merge the recipes and split the packages up so that bash isn't a mandatory requirement, maybe even using PACKAGECONFIG if that is useful. In related news I've been meaning to gut the alsa-utils recipe as that's the last recipe that actually depends on gtk2. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] bluez5: remove udev dependency
The commit message and the patch disagree: you're not removing the
udev dependency but allowing the user to remove it.
A better message would be 'bluez5: allow udev dependency to be
disabled with PACKAGECONFIG'
Ross
On Thu, 23 May 2019 at 17:42, David Frey wrote:
>
> udev is an optional dependency of bluez5, so use PACKAGECONFIG to allow
> users to decide if they want udev support.
>
> Signed-off-by: David Frey
> ---
> meta/recipes-connectivity/bluez5/bluez5.inc | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
> b/meta/recipes-connectivity/bluez5/bluez5.inc
> index aaf2af975d..93d1b4d8b0 100644
> --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> @@ -6,7 +6,7 @@ LICENSE = "GPLv2+ & LGPLv2.1+"
> LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
> file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
>
> file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e"
> -DEPENDS = "udev dbus-glib glib-2.0"
> +DEPENDS = "dbus-glib glib-2.0"
> PROVIDES += "bluez-hcidump"
> RPROVIDES_${PN} += "bluez-hcidump"
>
> @@ -22,6 +22,7 @@ PACKAGECONFIG ??= "obex-profiles \
> hog-profiles \
> tools \
> deprecated \
> +udev \
> "
> PACKAGECONFIG[obex-profiles] = "--enable-obex,--disable-obex,libical"
> PACKAGECONFIG[readline] = "--enable-client,--disable-client,readline,"
> @@ -43,6 +44,7 @@ PACKAGECONFIG[threads] =
> "--enable-threads,--disable-threads"
> PACKAGECONFIG[deprecated] = "--enable-deprecated,--disable-deprecated"
> PACKAGECONFIG[mesh] = "--enable-mesh,--disable-mesh, json-c ell"
> PACKAGECONFIG[btpclient] = "--enable-btpclient,--disable-btpclient, ell"
> +PACKAGECONFIG[udev] = "--enable-udev,--disable-udev,udev"
>
> SRC_URI = "\
> ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
> --
> 2.21.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4] python*-setuptools: add separate packages for pkg_resources module
On Fri, 2019-05-24 at 10:29 -0700, Khem Raj wrote:
> On Wed, May 22, 2019 at 3:58 AM Luca Boccassi m> wrote:
> >
> > On Tue, 2019-05-21 at 19:06 -0700, Khem Raj wrote:
> > > On Tue, May 21, 2019 at 5:36 AM <
> > > luca.bocca...@gmail.com
> > > > wrote:
> > > > From: Luca Boccassi <
> > > > luca.bocca...@microsoft.com
> > > > >
> > > >
> > > > The pkg_resources Python module is useful by itself, for
> > > > example
> > > > for
> > > > automatic loading of resources shipped in a Python package.
> > > > Add separate packages for it, so that users can depend on them
> > > > individually and avoid pulling in the entire setuptools, which
> > > > include scripts to download other packages, which might not be
> > > > desired on minimal images.
> > > >
> > > > Other distributions like Debian and Ubuntu already split
> > > > setuptools
> > > > and pkg-resources in this way.
> > > >
> > > > The setuptools packages now depend on the new pkg-resources
> > > > packages,
> > > > to avoid regressions for other packages that depend on them
> > > > already.
> > > >
> > > > Signed-off-by: Luca Boccassi <
> > > > luca.bocca...@microsoft.com
> > > > >
> > > >
> > > > ---
> > > > v2: restrict new RDEPENDS to class-target. As advised by
> > > > Alexander,
> > > > bitbake
> > > > cannot resolve native rdeps that mention package names
> > > > rather
> > > > than
> > > > recipe names.
> > > > v3: manually add RPROVIDES to the native class instead of
> > > > restricting the
> > > > RDEPENDS to the target class as a better workaround. Also
> > > > document why
> > > > the package is being split.
> > > > v4: re-send to the correct thread, no changes.
> > > >
> > > > meta/recipes-devtools/python/python-setuptools.inc | 11
> > > > +++
> > > > 1 file changed, 11 insertions(+)
> > > >
> > > > diff --git a/meta/recipes-devtools/python/python-setuptools.inc
> > > > b/meta/recipes-devtools/python/python-setuptools.inc
> > > > index 357aa07086..f49e078697 100644
> > > > --- a/meta/recipes-devtools/python/python-setuptools.inc
> > > > +++ b/meta/recipes-devtools/python/python-setuptools.inc
> > > > @@ -37,3 +37,14 @@ do_install_prepend() {
> > > > }
> > > >
> > > > BBCLASSEXTEND = "native nativesdk"
> > > > +
> > > > +# The pkg-resources module can be used by itself, without the
> > > > package downloader
> > > > +# and easy_install. Ship it in a separate package so that it
> > > > can
> > > > be used by
> > > > +# minimal distributions.
> > > > +PACKAGES =+ "${PYTHON_PN}-pkg-resources "
> > > > +FILES_${PYTHON_PN}-pkg-resources =
> > > > "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
> > > > +# Due to the way OE-Core implemented native recipes, the
> > > > native
> > > > class cannot
> > > > +# have a dependency on something that is not a recipe name.
> > > > Work
> > > > around that by
> > > > +# manually setting RPROVIDES.
> > > > +RDEPENDS_${PN}_append = " ${PYTHON_PN}-pkg-resources"
> > > > +RPROVIDES_append_class-native = " ${PYTHON_PN}-pkg-resources-
> > > > native"
> > >
> > > do we need to handle nativesdk case ?
> >
> > Hi,
> >
> > The parsing step of "bitbake core-image-minimal -c populate_sdk"
> > works,
> > while without the append_class-native workaround it fails
> > immediately.
> > Is this enough or is there something else I should run to check?
> >
>
> yeah usually to test nativesdk we need to do it with generated SDK
I do have a nativesdk target in the distro at $work, but I realise it
might be different enough. Is there a simple config change/command to
generate it from Poky?
--
Kind regards,
Luca Boccassi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Should systemd be marked as incompatible with musl?
On Fri, May 24, 2019 at 03:25:57PM -0700, Andre McCurdy wrote: > On Fri, May 24, 2019 at 1:28 PM Adrian Bunk wrote: > > On Fri, May 24, 2019 at 12:34:23PM -0700, Andre McCurdy wrote: > > > On Fri, May 24, 2019 at 11:46 AM Adrian Bunk wrote: > > > > On Fri, May 24, 2019 at 11:04:50AM -0700, Khem Raj wrote: > > >... > > > > > I think we should put in plan for 2.8 and define the scope, since we > > > > > are switching > > > > > poky defaults to systemd, > > > > > > > > Switching glibc builds to systemd as default is a reasonable decision. > > > > > > > > Switching musl builds to systemd as default would be very bad. > > > > > > > > Combining a tiny C library with a huge init system completely misses > > > > the configurations where the tiny C library actually makes sense for > > > > users. > > > > > > For new projects yes. However I know of a project (a big project, > > > shipping millions of devices) which picked systemd and glibc long ago > > > and is now running out of space. They already have various solutions > > > to free up Flash (some apps switched to being runtime downloadable, > > > etc) but if/when more savings need to be found then switching from > > > glibc to musl might be a less invasive change than switching from > > > systemd to some other init system. We obviously shouldn't make > > > decisions for OE today based on the historical decisions of one > > > project, but I just want to make the point that real world projects > > > have a lifetime and may end up with a combination of systemd + musl > > > due on past decisions that may not make sense for a new project > > > starting today. > > > > I am feeling guilty that there are two only partially related > > topics mixed in this discussion. > > > > In this part of the discussion the topic was what the default > > (and CI-tested) init system for musl should be - it seems obvious > > to me that systemd is not what users will usually want to use with musl. > > It would be great to have an alternative init system option for > smaller devices in oe-core. I don't think collectively we have the > development capacity to support it though (it's probably far more work > than properly fixing all the currently known issues with systemd on > musl...). Is there development capacity to support musl? Supporting musl is a real pain across the board, with new issues all the time. For really tiny systems you need both a tiny C library and a tiny init system, so not properly supporting the combination of both forces users to use alternative options instead of OE. Which minimizes the benefits gained by the pains of supporting musl. > > But there is also the topic whether systemd on musl is > > in a state that it should be made available at all. > > I think it's wrong to remove stuff from oe-core just because it isn't > perfect or isn't CI tested. Having something in oe-core means there's > a common version to collaborate on. If it gets kicked out then > development efforts inevitably fragment. Users are generally smart > enough to understand the concept of an experimental feature - although > we could perhaps do a better job of identifying them. Maybe one day > when users can create a custom distro config by running "make > menuconfig" there will be an option to enable experimental features > and the combination of musl and systemd would be hidden behind that. > Until then, perhaps we could add a sanity check warning if musl and > systemd are enabled together? That would be an improvement. But it conflicts with the intention to make systemd the default and CI-tested init system for musl. >... > > At that point my email that started this thread becomes relevant, > > the fact that the systemd/musl patches in OE add new security > > vulnerabilities and other bugs - and none of the systemd-on-musl > > proponents seems to consider this a problem they have to fix ASAP. > > It's certainly a problem and we should try to fix it. It's not at all > uncommon that patches to fix build issues with musl, clang, a new > version of gcc, etc have a life cycle... a first pass just to fix the > build and then updates as issues are found or better solutions get > merged upstream. It's the normal process. You could argue that we are > sometimes too quick to merge the first pass hacks and too slow to > review and update them, but unfortunately that's just a consequence of > limited developer resources (and it's always more fun to try to get > the latest version of something working than review and cleanup old > patches...). If upstreaming is possible at all. With systemd on musl there is also the fundamental problem that neither of the upstreams is interested in compromising their software for the other. Not to blame either of them, there is simply a fundamental conflict between the systemd "use all functionality available" and the musl "be a tiny C library" and "follow standards and provide only some GNU extensions". One example: systemd uses qsort_r. musl upstre
